This repository is intended to keep track and manage all what is not code-related. Requirements and Pre-Requirements discussions should be handled here too.
Home Page: https://waffle.io/radicalfx/housekeeping
The issue we are currently facing is that having all the projects, that ends up in different NuGet packages, complicates the release of a single package/project.
In light of having a build server what I expect to be able to do is via GitFlow:
develop:
develop the build server kicks in, builds the project, creates the NuGet package and pushes it to MyGet;master the build server kicks in, builds the project, creates the NuGet package and pushes it to NuGet;Not only, having multiple repositories force us to think much more to features that span multiple projects. Only a good thing.
We should start using this on all repo:
https://github.com/editorconfig/editorconfig-visualstudio#readme
in order to have the same indent/space/tabs, etc...
prevent-increment-of-merged-branch-version: true
Related to #35
At the time of this writing we have 12 pending PRs among which some quite old.
Obviously due to the fact that Radical is not our main focus, unfortunately we need to work as well, it is sometimes hard to commit, this is obviously complicated by the fact that the maintainer group is super small (@micdenny and I) and the we cannot merge our own PRs rule is causing some pain.
I actually see two possible approaches:
@micdenny comments? thoughts?
Create a set of Code Analyzers, based on Roslyn, to guide developers to gain the best from Radical
//cc @micdenny
logo proposal:
advantages:
Radical FrameworkWhat does it mean?
Using housekeeping as the baseline
Add to the above list for evaluation
the last thing, a little bit out of the scope, is that embedding Radical
dll(s) in the application executable seems not to be possibile (this could
be a nice feature when you want to distribute an application in 1 file),
because some dll are loaded dynamically at runtime searching on physical
path, I had to exclude from embedding this files:
System.Windows.Interactivity.dll,
Radical.Windows.Presentation.CastleWindsor.dll,
Radical.Windows.Presentation.dll
probably I have to investigate deeper this, in that case I'm using
SmartAssembly (by redgate) and I should also try withILMergeor
ILRepack.
Currently, IMO, the release process is a bit too complicated. The user need to manually bump the version number, not expected. Then we need to remember to release in production bumping again the version number in another place on a different branch. Once a thing is merged into develop we have no standard way to keep track that it needs to be released. Other than this we have master and develop that tend to complicate things.
What if:
Related to #6 what about merging the "Radical.Windows.Presentation.Puzzle" projects for Universal Apps into the "Radical.Windows.Presentation", in the end we are shipping the PuzzleContainer in any case and adding to the Radical.Windows.Presentation project 5 more classes should not be a problem at all compared to one less dependency to download from Nuget.
@enosrecanati @micdenny comments?
From @mauroservienti on October 30, 2014 5:56
As part of the release management improvements (#80 & #82)
Copied from original issue: RadicalFx/Radical#93
We have the @radical-bot user that can be used to create a TAG and push is back to the repo, in order to make it work we need to generate a security token for the user and change the AppVeyor config adding the following: https://www.appveyor.com/docs/deployment/github
The changes that need to be done are:
skip_tags: true to the develop and master config so that a tag doesn't trigger a buildmaster deploy section: - provider: GitHub
release: $(GitVersion_NuGetVersion)
description: 'Release v$(GitVersion_NuGetVersion)'
auth_token:
secure: 2ijF4OfPYfIUTunubL/Z04ogADL9sx/gKW1jMRNJnAa1OpHZpSvCKmP0gvNs8C7h
artifact: /.*\.nupkg/, src\build\Release.zip
on:
branch: master
Related to #35
Depends on #35. if not needed anymore remove the Radical.Build repo
Related to #35
as you can see in some packages there's the icon in some other not:
all the radical nuget packages need the new radical icon:
Which is the impact?
The entire documentation is in the WiKi repo of the Radical Desktop project.
We can go on adding doco there with no issues even if we reference something that is not there, such as the Universal Apps support, or we can:
Benefits of "2" are:
Current PuzzleContainer implementations are not aligned:
Missing features:
Should we?
Could be nice to have an integrated "chat to the development team" as a added support feature.
Gitter provide such a service, you can get unlimited public rooms and one-to-one chats, free forever.
See it in action on ChocolateyGUI repo
I dream about having common projects and dedicated version projects only for files that differs, using shared project.
As far as I know in vs2013 this could be achieved using this Shared Project Reference Manager visual studio extension, but in vs2015 they add new, lets say native, templates for shared project.
Any thoughts?
Think about supporting third party UI toolkits, such as, but not only, http://wpftoolkit.codeplex.com.
Both for Desktop and Universal Apps.
Our goal should at least to provide basic integration for the UI Composition framework or specific feature for Universal Apps
I think we should introduce well-known documentation paths, we have the quick-start and the VS templates, in both cases the dev reaches the same result a running application that does nothing.
In order to drive the dev in the right direction, where right in my opinion means "adhere as much as possible to the MVVM tenets", we should add the concept of "What's next", or some way to drive the dev exploring the documentation.
Which type of devs look at our documentation? Personas:
What do they expect as docs?
Remove from the Nuget profile legacy packages
https://www.nuget.org/profiles/radical
We have a strong dependency on a DI container, like it or not that's a fact.
Given the way things are actually designed implementing support for a container is a nightmare that comes to life. It is up to the user to understand what to register, how, when, and how to deal with BootstrapConventions. It is everything but a trivial task.
Now that we are going in the direction of a high level, DI container independent, ApplicationBootstrapper (See RadicalFx/Radical.Windows.Presentation#21 and RadicalFx/radical-universal#28) that utilizes a IContainerBootstrapper implementation as a mediator when talking to the DI container, I'm wondering if there is any value in moving the responsibility of deciding what to register, and how and when, to the ApplicationBootstrapper making the IContainerBootstrapper responsible for the physical registration only.
The clear advantage is that we move in the direction of making the task of implementing support for a new container a trivial task.
@micdenny thoughts?
The idea is to be able to plugin something like the API Comparer to verify breaking changes at build time and fail the build if any.
Currently everything is hosted under "topics.it" as radical.topics.it. I think we should move away from my domain and register a dedicated one.
Unfortunately "Radical" is a very common world :-|
ideas are welcome :-)
Our very simple process states:
master or developSo far so good, lovely.
Now, the issue (or at least potential issue) of the 4-eyes merge process in our scenario depends on the fact that we are not full time committed to the project, obviously. For the sake of the sample take into account the following scenario:
Presentation-something packageRadicalSo:
Radicaldevelop, so to publish the package to the MyGet feeddevelop, so to publish the package to the MyGet feedMyGet feedmaster branchAny way to improve the above scenario?
MyGet only, the package even if the PR is not merged yet adding to the package name the source branch name as well, pollutes the MyGet feed but solves the above scenario very easilyThe latest one is my preferred approach.
From @mauroservienti on May 31, 2015 9:35
https://github.com/Fody/Obsolete
Copied from original issue: RadicalFx/Radical#166
We can now enable 2 things:
master or developThe latter could be interesting because we could enlarge the team
The website is broken :(
http://www.radicalframework.com/
I see a lot of value in this:
http://www.cazzulino.com/automating-github-octohooks.html
Can we benefit of something?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.