Page History

...

Two git branches are created at feature freeze for each quarterly NetBeans release.

• The release branch (eg. release140) is used for release candidate and release builds. Naming is important as it is picked up by the build system (the last zero is a legacy of the old version scheme).
• The delivery branch is used for collating fixes for the release.

All pull requests intended for the release are merged to delivery, and delivery is merged to both the release branch and master branches regularly. The delivery branch is transitory and should be deleted shortly after the final release.

...

1. Change the current milestone on all remaining open pull request to the next milestone (use bulk edit in the PR table).
2. Create the delivery and release branches from master. Announce feature freeze and branching - see / adapt example.
3. At the time of branching, update plugin center and update center redirects https://github.com/apache/netbeans-antora/blob/main/supplemental-ui/.htaccess.
4. Clone the update center on the NetBeans VM, see also Update centre .htaccess.
5. Increment module spec versions on master for the next release using ant increment-spec-versions. This should be the first commit in master after branching. See PR after NB14 branch.
6. Add the metadata about the release to netbeansrelease.json, including a milestone for rc1 using the hash from the release branch (eg. git show). This will be the last hash shared with any other branch.
7. Trigger a build for the release branch in the Jenkins NetBeansTLP job. A build may have started automatically but will likely not have picked up the latest metadata - if so, stop and restart. Build with parameters – 'installers', 'vscode plugin', and 'push to nightly'. For every release candidate, each of these need to be selected, generating multiple binaries ('installers' will generate three, two Linux, deb and rpm, and one Windows, because Mac installer has to be generated on a Mac).
8. Once the build is complete, download the source and binary zip artefacts, and check build, fixes, etc. locally. Lock the Jenkins build to stop it being cleaned up, and announce the release candidate with links to the artefacts - see / adapt example.
9. Add a pinned GitHub discussion with links to the release candidate: https://github.com/apache/netbeans/discussions/6581, share it on social networks beyond the dev list.

...