[DISCUSS] Making quarterly releases (more) manageable

[Neil C Smith <ne...@apache.org>]

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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists