Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1.  Announce the feature freeze date on dev@ using [NOTICE] emails a week and a day before branching - see / adapt example.
  2. Change the current milestone on all remaining open pull request to the next milestone (use bulk edit in the PR table).
  3. Create the delivery and release branches from master. Announce feature freeze and branching - see / adapt example.
  4. At the time of branching, update plugin center and update center redirects https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess.
  5. Clone the update center on the NetBeans VM.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Over the following week, review and merge any inbound fixes to delivery.
  11. As soon as there is any change in delivery, open two pull requests to sync branches - Sync delivery to releaseXXX for XX-rcN (see example) and Sync delivery to master after XX-rcN (see example)
  12. If there are no merged fixes and no open major / critical issues for this release, consider whether it's time to move to a vote. The release voting candidate must be built off the same git hash as the last release candidate - edit the existing milestone in netbeansrelease.json.
  13. If / when ready to trigger another release candidate, check and merge the sync PR to releaseXXX. Add a milestone based on the git hash of the sync PR merge commit to netbeansrelease.json.
  14. Repeat from step 6, making sure to merge the other sync PR to master after verifying and announcing the release candidate. Do not sync to master if there are problems with the release candidate build - fix in delivery and resync / rebuild.

...

Code Block
languagetext
titleMailNotice email
collapsetrue
<SUBJECT>
[NOTICE] Apache NetBeans XX release candidate YY available for testing

<BODY>
Hi,
 the nth Release candidate for NetBeans XX is ready.

The NetBeans XX-rcYY artifacts are here:
https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/XX/BNUM/artifact/dist/

You will found linux/windows installer and vsix file too

Link to the binary zip:
https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/XX/BNUM/artifact/dist/netbeans/netbeans-XX-rcYY-bin.zip

SHA512:
<INSERT SHA512>

The sources are here:
https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/XX/BNUM/artifact/dist/netbeans/netbeans-XX-rcYY-source.zip

SHA512:
<INSERT SHA512>

If you're a committer adding an issue, or helping triage an issue (please do!), add the milestone and/or priority labels as appropriate.
Use priority:high for should be fixed before release, priority:critical for must be fixed before we can release.

**The following rules are applied to pull requests from now until release:**

PR's intended to be included in the XX release :
 - Limited to fixes (no need for a ticket!)
 - Base on the delivery branch.
 - Mark with NBXX milestone (we'll monitor - no need to add us all as reviewers!).
 - Will be merged by the release team.
 - Will be assessed against bug priorities - please use the priority:high and priority:critical labels here too.

PR's with features for NBXX+1 :
 - Base on the master branch.
 - Will be reviewed and merged in the usual way.
 - If possible stay away from big refactoring.
 - If possible do not overlap with fixes for XX (delivery will be merged to master weekly).


Thank you for your contributions!

Best regards,
RM

...