Page History

...

Apache NetBeans

...

See impetus and mailing list links (below) for more information.

Key points

• Four releases a year on known dates (within reason, weekends, blockers, etc.).
• Everything merged to master at all times is intended and ready to be included in the next scheduled release.  No or minimal cherry-picking to release branches.  Keep master releasable.
• Each release has a fixed and well known feature-freeze date. Features may be targetted for releases, but no promises are made of features being included unless they have been merged to master by that date.
• Merging earlier rather than later in the merge window is to be encouraged!
• After the feature freeze date only fixes intended for the release should be merged to master until the next feature window opens. Aside from any release-specific commits, the release branch will be kept in sync with master.
• All fixes merged to master after the feature-freeze date should be made in accordance with the Bug Priority Guidelines
• One release a year is designated a long-term / extended support version -
  • Only this release has a full NetCAT process, and subsequently a much shorter (month less) merge window to accommodate it (and because the emphasis for this release should be on fully stabilising features added in the previous 3 releases).
  • For 9 months of the year that means that people have a choice of two downloads (need to consider how to describe that, and what if any infrastructure concerns that brings?).  NetBeans 11.0 remains available until April 2020.
  • Minimal serious bug fixes might be backported to the LTS release and pushed via UC, taking into account the Bug Priority Guidelines (critical or blocker affecting significant users?) These should be done on the relevant release branch.
  • Users needing features should be encouraged on to the faster release train, and help test those features before next LTS.
  • Major version number is incremented for LTS.  So NetBeans 12.0 would be in April 2020.  Perhaps counter-intuitively the major version number would be increased for the versions with least new features. (Consider NetBeans 11.1 equivalent to NetBeans 11 feature update 1?)

Schedule

is released quarterly according to the following schedule.

NB. The dates here are deliberately mid-month, two weeks after previously suggested.  Because no-one wants to do a release on New Years Eve, and it potentially gives a little more leeway in releasing / testing with JDK releases?

Questions still to be answered?

• What is NetCAT lite?  Do we need to consider labelling in PRs for specific NetCAT sections / tribes to be consulted?
• Kafka page (below) has both feature freeze and code freeze (blockers only) dates - do we need similar?
• Would the dates above be better specified to always be on the same day - eg. as week in the year, or second Wednesday in April, etc.?
• How much of the release process can be configurable in the build?  Could we get to a point that release branches are not required, and a tag could be used - is that desirable?
• Do we allow limited bypass of feature freeze?  By mailing list vote?
• Do we need a short-lived general "next" branch or specific short-lived feature branches to merge PRs where there's a need to collaborate or bring together interdependent things after feature freeze?
•  ... ???

Impetus

In mid-2018 there was a rough consensus on moving to a fixed three-month schedule for Apache NetBeans release.  However, as of May 2019 we had not fully achieved that transition, with some aspects of feature-based releasing still in play (eg. September release earmarked as NB12 because it will contain C/C++ support, but what if that's not ready?).

This page attempts to pull together various comments made on the dev@ mailing list, along with some other projects' reasoning and methodology around time-based releasing (non-comprehensive links below!). It attempts to pull in various thoughts people have made about simplifying the release process, how NetCAT realistically fits in with this new release schedule, whether such frequent releases can be as stable, and whether all users (particularly corporate / education) want to update so frequently?

Links

https://lists.apache.org/thread.html/ff506c4a56f267a1b616c18ae218301b3e6d386ce618940e32faaea3@%3Cdev.netbeans.apache.org%3E - lazy consensus thread on adopting this schedule

https://lists.apache.org/thread.html/ea5189b51477cfca2b18e9c122872d36ab3ef6d9babf27c4aa649c3d@%3Cdev.netbeans.apache.org%3E - discussion thread on this schedule

https://lists.apache.org/thread.html/903873879219d2852e0889b14e4e8d1e4135c15bbe68f370245d10ad@%3Cnetcat.netbeans.apache.org%3E - original discussion thread on quarterly releases

https://lists.apache.org/thread.html/cc5575ac4173b8a934e78d300b1063013606be00ffc7d8d30b00419b@%3Cdev.netbeans.apache.org%3E - another original discussion thread on quarterly releases

Time Based Release Plan - Apache Kafka

Key points

• Four releases a year on known dates (within reason, weekends, blockers, etc.).
• 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!
• After the feature freeze date, fixes intended for the release should be merged to delivery until the next feature window opens. The delivery branch will be merged to both master and release branches on a weekly schedule.
• All fixes merged to delivery after the feature-freeze date should be assessed and reviewed in accordance with the Bug Priority Guidelines

History

In 2019 there was a decision to move towards a time-based, quarterly release schedule for Apache NetBeans releases.  This started from Apache NetBeans 11.1, and retrospectively designated Apache NetBeans 11.0 as an LTS release.

At the end of 2019 the schedule was shifted back by one month, to avoid the end of year period. At the end of 2020, master freezing was replaced by a move to a delivery and release branch mechanism.

In early 2021, a decision was made to review the process and requirements for LTS releases, and in October 2021 a decision was made to concentrate solely on quarterly releases, changing the numbering scheme accordingly. No further LTS release will be made.

Further details, notes, and discussions : Notes and Discussions on the Release Schedulehttps://wiki.mozilla.org/Release_Management/Calendar - Firefox release schedule