Hi All, I realise this is partly starting a thread that has overlap with Geertjan's 12.3 postmortem one. The joy of having two RM's is you occasionally repeat each other! :-) However, this is partly to consider some tweaks to the current release schedule / process to make it more manageable. 12.3 is out, it was a little late (partly due to nb-javac integration delay), but not too bad considering we also did feature freeze late because we didn't have a release manager in place. As Laszlo said in [1] "I'm feeling that having 4 releases in a year is a bit too many..." - well, now we've agreed to keep to 4, how do we do that and ensure it doesn't become too many?
I'll kick off with 3 things I think we could do (or need to consider) from here - 1. Make sure we have a release manager (or managers!) in place from the time of the previous release. 2. Do a beta release 2-3 weeks before feature freeze, and rename post-freeze pre-voting binaries as release candidates. 3. Figure out a better way of assessing what should go in after freeze and how we manage JIRA tickets against bug priority guidelines [2]. On 1, Geertjan and I have talked about taking this on jointly again for 12.4, but with me having more of a backup role - a good test we've gone over and documented all aspects of the current process! :-) Are we OK with that? On 2, this is perhaps the bigger change I'd like to suggest - let's get people testing the release earlier. Laszlo made a great change in 12.2 to using a delivery branch, which has given us most of the benefits of master freeze with fewer of the downsides. I was personally less sure about having betas and release candidates after release branching, but it got me thinking about what we mean by those terms, and what we originally agreed we'd do in having quarterly releases. If we make the release branch and a beta 2-3 weeks before freeze, we can get broader testing and feedback on changes, and it will also hopefully encourage landing bigger features earlier in the process. On 3, .. well, I'm not quite sure what we actually do about 3. I felt the need to push back a number of times during 12.3 against the idea that it is the release manager that decides whether something gets pulled into a release. That really should happen only as a last resort. Somehow we need to ensure incoming JIRA tickets and PRs are properly assessed against the bug priorities, by those best placed to make those assessments. Release managers should ideally be keeping an overview on the integration process, not having to decide what gets integrated or needs chasing up (not to say we won't have an opinion on aspects of the IDE we use day to day) Somehow, in making quarterly releases manageable, I think it's worth at least considering these 4 points we originally discussed and agreed. * Each release has a fixed and well known feature-freeze date. Features may be targeted for releases, but no promises are made of features being included unless they have been merged to master by that date. * Everything merged to master *at all times* prior to feature freeze is intended *and ready* to be included in the next scheduled release. Keep master releasable! * Merging earlier rather than later in the merge window is to be encouraged! * All fixes merged to delivery after the feature-freeze date should be assessed and reviewed in accordance with the Bug Priority Guidelines. Any thoughts, ideas, etc.? Best wishes, Neil [1] - https://lists.apache.org/thread.html/r9ea55f3d1e14186bd9f149c8771308cf0a5bf3c2ef784604e8e1c764%40%3Cdev.netbeans.apache.org%3E [2] - https://cwiki.apache.org/confluence/display/NETBEANS/Bug+Priority+Guidelines --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
