Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Discussion]Versioning and Release Schedule #2798
With the release of v6 out of the way I thought it would be a good idea to get mvvmcross back on to a regular cadence for releases, as well has have a generally understood versioning strategy.
Minor and Major updates will be made as required but with a view that minor updates would aim to be done every 3 months, and major updates, once a year.
As mentioned previously, for each monthly revision a new branch would created which maps to the beta nuget package for that release. This branch would pick up all bug-fix PRs that have been merged into develop over the prior month. Upon release, the revision branch is merged into master
For minor and major releases I suggest having dedicated branches for those releases. PRs for new features would be raised against the appropriate release branch. Unfortunately this does add a bit of overhead in terms of rebasing against develop. However, since the merged PRs on develop should be restricted to bug fixes, with no breaking changes, this overhead should be kept to a minimum.
Projects and Milestones
Milestones should be used to tag issues (bugs and features) with the expected release. So for a bug that's raised against v6.0.0 it would be added to the v6.0.0 project with a milestone of v6.0.1
I'm sure there are aspects of this that will need tweaking but I thought I'd get the ball rolling so that we can get something in place.
This is blocked until Visual Studio 15.7 is released and running on AppVeyor.
As for regular planned releases, I am all in for that, it is easy to manage with the CI we have, we just need to create a
As for versioning, we already follow the versioning you suggest. It is called SemVer 2.0, we won't change anything here.
As for testing a release, what kind of testing do you propose we do? Right now we only rely on a couple of Unit Tests passing and manual tests done on the Playground samples when working on PR's.
w.r.t. versioning - I should have referenced SemVer 2.0. I guess my point here is that we should try to stick to this closer, which is only possible if we start to manage different branches for bug fixes versus new features.
w.r.t. testing - my point was just to separate out a beta, prior to the end of the month, allowing users of mvvmcross to grab the beta, give it a try and confirm that it doesn't break anything. Particularly for the monthly bug-fix releases, this should be relatively low impact to manage, My recommendation would be to revert any commits that are causing issues, rather than attempting to fix them for that release - this will prevent any slippage with the monthly release from having to retest the new fix.
My recommendation is automatic CD. No branching. No releases. If folks want that they can pay you for it. I'm serious. If they don't like the CD friction then pay for access to a stable LTS myget feed. I'll probs be doing this over at ReactiveUI. Folks get too much stuff for free without giving back.