Proposal to align development month with calendar month, and move the release from the 22nd to the 14th
TL;DR: Reduce potential confusion by moving RC1 and the feature freeze to the 1st, and moving the monthly release to the 14th. The development month would be beautifully aligned with a calendar month, development milestones would be "March 2017" etc, and release milestones would continue to be as they are now.
Current process
- A release month runs from the 23rd to the 22nd, when GitLab x.y.0 is released. Today we are in release month 8.17 (Jan 23-Feb 22).
- A development month runs from the 8th to the 7th, when GitLab x.y.0 RC1 is released and the feature freeze goes into effect. Today we are in development month 9.0 (Feb 8-Mar 7).
- Issues milestones are set based on the development month, since that's where developers are looking for what to work on. A regression found in 8.16.x or 8.17.x gets the 9.0 milestone, just like anything we want to get into GitLab 9.0.
- Merge request milestones are set based on the release month, since that's where Release Managers are looking for what to pick into stable branches. A fix for a regression found in 8.16.x gets the 8.16 milestone. A feature for 9.0 gets the 9.0 milestone. An MR that isn't urgent at all gets no milestone at all.
Problems
- It's confusing that the release and development months are not aligned, but use the same names and milestones (8.17, 9.0, 9.1).
- Because we're using the same milestone for 2 different concepts with different date ranges, we cannot use the milestone due date (should it be the 7th or the 22nd?).
- We cannot close a milestone until a few months after that development month ends, since it needs to be kept open to create regression MRs in. This means it's easy to accidentally create issues in the release milestone (8.17) instead of the active development milestone (9.0).
- It's very counterintuitive to put a 9.0 (development month) milestone on an issue for an 8.17 (release month) regression.
- With seemingly arbitrary dates, it's hard to keep track of the specific rules. For example, is the feature freeze on the 7th or before the 7th? What happens if RC1 is created a few days later for whatever reason? Does something merged on the 6th always get in? What about the 7th? What about the 8th? Do I need to do anything to still get it into the next release? Does this depend on whether RC1 was released on the 7th or after? If it's the 8th today, what release am I supposed to be creating issues or merge requests in?
All of the above is documented and there is a good reason to use 9.0 for regression issues, but 8.17 for regression MRs, but despite all that, @smcgivern and I are finding ourselves explaining the scheme and the reasoning and the specific dates a few times a week to both new people and those who have been here a while, which means we should do something to make all of this more elegant and less potentially confusing.
To resolve the first four problems, we could start using separate milestones for the release month (23rd-22nd) and development month (8th-7th). We could call them something like "Release 9.0" and "Develop 9.0", but that's not a lot better and still leaves plenty of room for confusion.
I propose to go one step further, and align our development months (currently 8th-7th) with calendar months (1st-29/30/31st). This would move RC1 and the feature freeze from the 7th to the 1st, and the monthly release from the 22nd to the 14th, since we don't need or want more than 2 weeks between RC1/feature freeze and the final release. With this beautiful alignment of development and calendar months, development milestones could be "February 2017", etc, and release milestones would continue to be numbered 8.17 etc as they are now.
This would resolve the listed problems, and we'd end up with a very elegant and easy to understand scheme: We develop during a calendar month, with the last day of the month being the last day you can get stuff into the next release, and then release 2 weeks later on the 14th.
It sounds a bit scary to move away from the sacred 22nd release date, but in the end, there's really nothing that makes the 22nd special beyond "we've always done it this way", and we can change it without major issues as long as we're consistent going forward.
I propose to start working like this with 9.1, and announce the new scheme with 9.0. That means 9.1 will be released on April 14th, and that the March 2017 development month will run from March 8th to March 31st. This means that the 9.1 development month will be one week shorter than normal, but as we've shown with 8.17 where the same thing was the case, 3 weeks is plenty for us to push out some awesome stuff. From the 9.2 development month (April 1st-30th) onwards, we'd be back to having a full calendar month.
@sytses @dzaporozhets @JobV @stanhu @smcgivern Thoughts?