New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion]Versioning and Release Schedule #2798

Closed
nickrandolph opened this Issue Apr 15, 2018 · 8 comments

Comments

Projects
3 participants
@nickrandolph
Contributor

nickrandolph commented Apr 15, 2018

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.

Versioning
My suggestion for version numbering would be:
Major (eg v6.0.0) - substantial architectural or significant breaking changes
Minor (eg v6.1.0) - new features, possibly some breaking changes where unavoidable
Revision (eg v6.0.1) - only bug fixes (breaking change to be avoid, unless critical bug fix)

Schedule
I propose that we have a monthly cadence for new revisions. The main objective behind a strict monthly cadence for bug fixes is that it promotes community contributions - if someone submits a PR to fix an issue, they should know that once the PRs been merged, it will be published within a month (bug fixes only)
Each month:

  • Last PRs merged for next release on the 20th of the month (I was thinking 7 days prior to end of the month but this means the date each month would vary)
  • On the 20th of the month a new revision branch, eg releases/v6.0.1, would be greated and a new beta released to nuget
  • During testing of the new release, if any bugs related to the changes in the revision are found, they can be addressed by reversing the appropriate commit - the commit would be pushed to the following month for the issues to be resolved. In some cases it may be necessary to make changes to the branch but in this case the PR should be made against develop and the commit cherry picked into the release branch.
  • The revision is published on the first of the next month and the revision branch is merged into master

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.

Branching
Currently all development (ie issues and PRs) are raised against the develop branch. I suggest that going forward all bug-fix PRs would be raised against the develop branch.

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
I would suggest that a project is maintained for all major and minor releases. These projects remain open even after the release has been published to allow for bugs to be tracked against subsequent revision releases (eg the v6.0.0 project would track bugs that are to be released in v6.0.1)

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.

@nickrandolph nickrandolph added this to the 6.0.1 milestone Apr 15, 2018

@nickrandolph nickrandolph added this to TODO in MvvmCross 6.0 via automation Apr 15, 2018

@Cheesebaron

This comment has been minimized.

Member

Cheesebaron commented Apr 16, 2018

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 release/{major.minor.patch} branch and it will be magically picked up if it also has a git tag, we can always adapt this logic if a different workflow is needed here.

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.

@martijn00 martijn00 added this to To do in MvvmCross 6.1 via automation Apr 16, 2018

@nickrandolph

This comment has been minimized.

Contributor

nickrandolph commented Apr 17, 2018

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.

@Cheesebaron

This comment has been minimized.

Member

Cheesebaron commented Apr 18, 2018

The last point about beta, I dunno how that is different from what we have now where you can just grab latest build from MyGet and test on that?

@nickrandolph

This comment has been minimized.

Contributor

nickrandolph commented Apr 18, 2018

Two reasons:

  • having the beta builds via myget adds too much friction - most devs won't both switching to a different repository for packages. Nuget is bad enough without having to deal with packages from different sources
  • further more, most devs won't bother with nightly builds. If there is a focus point, eg a beta for the next release, it should get more traction and hopefully over time, more stability
@nickrandolph

This comment has been minimized.

Contributor

nickrandolph commented Apr 24, 2018

An addition to the proposal:

  • PRs to remain open for a minimum of 24hrs after the last commit

@nickrandolph nickrandolph modified the milestones: 6.0.1, 6.0.2 Apr 30, 2018

@ghuntley

This comment has been minimized.

Member

ghuntley commented May 6, 2018

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.

@nickrandolph

This comment has been minimized.

Contributor

nickrandolph commented May 6, 2018

Great long term plan but in the short term Wen don’t have the test matrix to be able to do CD. Need a short term release frequency that ensures we can get bug fixes out in reasonable time to encourage contributions

@nickrandolph nickrandolph modified the milestones: 6.0.2, 6.x Jun 5, 2018

@nickrandolph

This comment has been minimized.

Contributor

nickrandolph commented Jun 6, 2018

Hi all, closing this issue as it was more of a discussion doc than anything. It would still be good to capture the workflow somewhere so that anyone wanting to contribute knows where to look

MvvmCross 6.1 automation moved this from To do to Done Jun 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment