...

1. You must be a PMC member in Apache NetBeans.
2. You must have connected your Apache ID to Apache NetBeans GitHub via GitBox: https://gitbox.apache.org.
3. You must have access to https://github.com/apache/netbeans and https://github.com/apache/netbeans-jenkins-lib/.
4. You must be able to connect to Apache CI Jenkins instance builds, i.e., see 

   Jira
   server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key INFRA-17082

   .
5. You must have a PGP KEY (http://www.apache.org/dev/release-distribution.html#sigs-and-sums) for which the public key must be here: https://dist.apache.org/repos/dist/release/netbeans/KEYS.
6. You need to have sudo access to netbeans-vm1.apache.org (Eric Barboni Neil Smith Laszlo Kishalmi has this, at least).

Branching, builds and release candidate overview.

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. Before freezing, the plugin portal for the upcoming release should exist and dev should point to it. Maybe move everything from the previous to the new release. When we have our first release candidate, we should have plugins already in the plugin portal, to test the plugin functionality for the upcoming release.
2. Announce the feature freeze date on dev@ using [NOTICE] emails a week and a day before branching - see / adapt example.

After freezing, on the freeze date or shortly thereafter:

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 redirects https://github.com/apache/netbeans-websiteantora/blob/master/netbeans.apache.org/src/content/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, 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.

After the build is complete (weekly, bringing fixes into the delivery branch for the release, syncing them, triggering weekly release candidates):

1. Over the following Over the following week, review and merge any inbound fixes to delivery.
2. 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)
3. 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.. See also the criteria described at: Pull requests for delivery.
4. If / when ready to trigger another release candidateIf / 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.
5. Repeat from step 61, 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 / rebuildthe 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.

Moving towards a release vote:

1. The release voting candidate must be built off the same git hash as the last release candidate - edit the existing milestone in netbeansrelease.json. 
2. Instead of adding another hash, change what was the last release candidate to have, with version "vote:1", etc, see https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json#L1074
3. Do the build again, this time, only selecting parameters 'installers' and 'vscode'. Release build should never be pushed to nightlies.

Preparing the Code Base and Jenkins TLP Job

...

1. Create a branch release<version> in https://github.com/apache/netbeans. <version> looks like 113 for Apache NetBeans 11.3 full name of branch is release113
2. Create a milestone on github for next iteration. (to help triage)
3. Create a section for release<version> in https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json (after the copy paste, read carefully to match date, change version, change position.
4. Check on Jenkins that item appears for release<version> in https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/ (all previous branches should be present).
5. On freeze date create delivery branch to allow PR that will be resynch with release<version>
6. Normal development will continue on master but before merging normal PR do a PR to increment spec version

   ant increment-spec-versions

...

1. You have to set up json file milestone content.
2. Go to https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/
3. Check that the build on release<version> and verify artefacts they should be branded with beta in their name. Cancel and relaunch build otherwise
4. Wait for the job to be finished.
5. Keep the build

...

1. You have to set up json file milestone content.
2. Go to the https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/
3. Check that the build on release<version> and verify artefacts they should be branded with like a voting candidate. Cancel and relaunch build otherwise
4. Wait for the job to be finished.
5. Keep the build

...

Go to your local git repository clone. Collect the git commit hash from the release build job.

git fetch --all
git tag -a $VERSION -m "Apache NetBeans $VERSION." $HASH
git push origin $VERSION
# or if you've disabled upstream push
git push https://github.com/apache/netbeans.git $VERSION

...