Overview

Every PMC member should read the below docs at least once, several times, because the Apache NetBeans PMC members are responsible to verify and ensure releases are done in compliance with these rules:

See the generic Apache Release process – http://www.apache.org/dev/release-publishing.html.
See the generic Apache Release FAQ – http://www.apache.org/legal/release-policy.html.
See the ASF policy and documentation for releases: http://www.apache.org/dev/#releases.
See the necessary steps and requirements for the release distribution -- http://www.apache.org/dev/release-distribution.html.

Requirements

You must be a PMC member in Apache NetBeans.
You must have connected your Apache ID to Apache NetBeans GitHub via GitBox: https://gitbox.apache.org.
You must have access to https://github.com/apache/netbeans and https://github.com/apache/netbeans-jenkins-lib/.
You must be able to connect to Apache CI Jenkins instance builds, i.e., see INFRA-17082 - Getting issue details... STATUS .
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.
You need to have sudo access to netbeans-vm1.apache.org.

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.

The release team handle all merges to delivery, and syncing to other branches. This is mainly for scheduling reasons, as well as to keep an overview of fixes / check for merge issues. A wrongly timed (eg. between syncs) or unwanted (eg. spec version changes) commit merged to delivery will likely lead to a forced reset. The release team has no more say in what actually gets merged to a release than any other committer.

Syncing from delivery to master and release branches is done via pull requests. This has a number of benefits, including running CI against both targets with every merge to delivery, easy view of all changes between release candidates, and ensuring release hashes are unique to the release branch.

It is useful for all committers if we can use the same day of the week for release candidates and syncing. This has often been a Wednesday, but is up to the member(s) of the release team managing this for any release - publicise it!

Announce the feature freeze date on dev@ using [NOTICE] emails a week and a day before branching - see / adapt example.
Change the current milestone on all remaining open pull request to the next milestone (use bulk edit in the PR table).
Create the delivery and release branches from master. Announce feature freeze and branching - see / adapt example.
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.
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.
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.
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.
Over the following week, review and merge any inbound fixes to delivery.
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)
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.
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.
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.

Preparing the Code Base and Jenkins TLP Job

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
Create a milestone on github for next iteration. (to help triage)
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.
Check on Jenkins that item appears for release<version> in https://builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/ (all previous branches should be present).
On freeze date create delivery branch to allow PR that will be resynch with release<version>
Normal development will continue on master but before merging normal PR do a PR to increment spec version
```
ant increment-spec-versions
```

Taming JSON to Prepare Beta or Voting Candidates

https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json

For each release section you will have milestones section. This section will help branding a special Apache NetBeans milestone.

If nothing is set in the section, it will release a dev version of current branch, e.g., 11.3-dev.

Preparing for beta:

Milestone section key are commit hash. If you want a commit hash to form a beta1 you need to add milestone entry (do not forget position):

"<commit hash>":{"version": "beta1","position": "1"}

Branding will contain beta information.

Preparing for voting candidate:

Milestone section key are commit hash. If you want a commit hash to form a beta1 you need to add milestone entry (do not forget position):

"<commit hash>":{"vote": "1","position": "2"}

Branding will contain release information.

Producing a Release Candidate

1. Obtaining and preparing the files

1.1 On Apache Jenkins

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

1.2 On your computer once the build described in 1.1 above has succeeded:

Download and extract the build artifacts.

Check the SHA512 checksums:

find . -name '*.sha512' -execdir sha512sum --check '{}' \;
#alternative
for z in $(find . -name '*.sha512'); do cd $(dirname $z); sha512sum ./$(basename $z) --check --quiet; cd - >/dev/null; done

1.3 On the NetBeans virtual machine

Prepare apidoc folder according to json file:

sudo su -
cd /var/www/bits.netbeans.org
mkdir **version**

Producing a Voting Candidate

1. Obtaining and Preparing the Voting Candidate Files

1.1 On Apache Jenkins:

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

1.2 On your computer, once the build described in 1.1 above has succeeded:

Download and extract the build artifacts, specifically, "(all files in ZIP)" for "dist/netbeans" and "dist/netbeans-platform". This gets us the IDE, source and binary, NBM modules, and platform source and binary.

Check the SHA512 checksums:

find . -name '*.sha512' -execdir sha512sum --check '{}' \;
#alternative
for z in $(find . -name '*.sha512'); do cd $(dirname $z); sha512sum ./$(basename $z) --check --quiet; cd - >/dev/null; done

Sign the Release Files

export GPG_EMAIL="YOU@apache.org"
find . -name '*.zip' -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sign {} \;
# Stop here if nbms are not going to be published
find . -name '*.nbm' -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sign {} \;
find . -name '*.gz' -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sign {} \;
# nbm licenses
find . -name '*.license' -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sign {} \;
# nbm/updates.xml and nbm/tasks.jar
find . -name '*.jar' -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sign {} \;
find . -name '*.xml' -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sign {} \;

Verify Signatures

find . -name '*.asc' -exec gpg --verify {} \;

2. Verifying the Release by Checklist

Go through the Apache Incubator Release Checklist
(whether a project is in the Apache Incubator or not, these items need to be checked since they're important for all Apache releases)
Check the Product version:
Start Apache NetBeans and check the Title and the Help > About Dialog
Check that the splash screen has been updated.
Check that the user directory matches the release number.
Check GPL License is present and need to be accepted:
1. Start NetBeans with an empty User directory
2. Open a Java SE project: installing nb-javac shall present GPL
3. Start NetBeans with an empty User directory
4. Create a new PHP project: installing Graal JS shall present GPL

3. Publishing them in the staging area

Create an empty directory for the release then:

svn checkout --depth immediates https://dist.apache.org/repos/dist/ apache-dist
cd apache-dist/dev && svn update --depth immediates netbeans
cd netbeans && svn update --set-depth infinity

Publish to Staging Area

svn rm netbeans-platform/* netbeans/*
mkdir netbeans-platform/$VERSION netbeans/$VERSION
# Copy the netbeans-platform and netbeans artifacts with checksums and signatures in place
svn add netbeans-platform/* netbeans/*
svn --username "<your-apache-username>" commit -m "Apache NetBeans $VERSION."

Note 1: In the above $VERSION should be, for example, "12.3" (and not 12.3-vc or something similar), because then when we publish later to "release", we won't need to change the name.

Note 2: The above, i.e., pushing to svn, could take several hours.

4. Do the vote on the dev mailing list.

5. Creating tag for the Release:

Assuming the vote succeeded, we should tag the release, after voting, but not the voting candidates.

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

6. Releasing a Release

Assuming the vote succeeded, move the artefacts from "dev" to "release", which, on success, will automatically trigger mirroring:

# Go to the apache-dist directory which had been previously checked out in Step 4.
cd release && svn update --depth immediates netbeans
cd netbeans && svn update --set-depth infinity
# svn rm netbeans-platform/* netbeans/* # need to keep LTS and latest non-LTS ?
# Use svn move or copy to copy the the artifact from the staging area
svn mv ../../dev/netbeans/netbeans-platform/$VERSION netbeans-platform/$VERSION
svn mv ../../dev/netbeans/netbeans/$VERSION netbeans/$VERSION

Go to the release version directories and rename the voting candidate artifacts to have the release version in their name.
Adjust the name change in the checksum files (or recreate them)
Doublecheck the checksums with: find . -name '*.sha512' -exec sha512sum -c {} \;
Commit the changes from the apache-dist directory

7. Updating redirect for NetBeans Distribution Update Center

Once release is synchronized across all download mirrors it is necessary to update redirect for release modules to final location:

Login to NetBeans virtual machine where redirect is configured: ssh <your_apache_id>@netbeans-vm1.apache.org

Become root using e.g. OTP MD5 online encryption: sudo /bin/bash

sudo /bin/bash
cd /var/www/html/uc/
mkdir 11.1
cd 11.1/
curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/11.1/nbms/updates.xml.gz -o updates.xml.gz
echo ' RedirectMatch ^/uc/11.1/(.*)(\?.*)?$ http://www.apache.org/dyn/closer.lua?action=download&filename=netbeans/netbeans/11.1/nbms/$1' > .htaccess
# Update the previous version UC - need to keep LTS and non-LTS! 
cd ../10.0/
echo 'RedirectMatch ^/uc/10.0/(.*)(\?.*)?$ https://archive.apache.org/dist/incubator/netbeans/incubating-netbeans/incubating-10.0/nbms/$1' > .htaccess
vim updates.xml.gz

Modify updates.xml.gz file of previous release to contain: (how to handle LTS vs non-LTS?)
```
<notification url="https://netbeans.apache.org/download/index.html">Apache NetBeans IDE 11.0 is available!</notification>
```
element in its <module_updates> root element.

NOTE: For accessing the NetBeans Virtual VM please see netbeans-vm.apache.org

8. Post Release Step

8.1 Git operation post release create PR for snapshot (example for 12.5)

git checkout release124
ant clean
ant build
ant gen-sigtests-release
git add -A
git stash
git checkout master
git checkout -b apis-nb125a1
git stash pop
git add -A
git commit -m "Snapshot of APIs as of 12.5"
# remove getPeer() calls
find . -name "*.sig" -exec sed -i '/java.awt.peer.ComponentPeer/{N;d;}' {} \;
# check git diff
git add -A
git commit --amen

8.2 Git operation post release merge delivery to master

(wip)

website

mail to + twitter

--

clean up old release on dist, github tag removal, free jenkins locked build

Specific Steps, Details, and Examples

See these for reference:

NetBeans 12.3 tasks: NETBEANSINFRA-238 - Getting issue details... STATUS

NetBeans 12.1 tasks: NETBEANSINFRA-212 - Getting issue details... STATUS

NetBeans 10 tasks: NETBEANS-1321 - Getting issue details... STATUS

Space shortcuts

Page tree

Overview

Requirements

Branching, builds and release candidate overview.

Preparing the Code Base and Jenkins TLP Job

Taming JSON to Prepare Beta or Voting Candidates

Preparing for beta:

Preparing for voting candidate:

Producing a Release Candidate

1. Obtaining and preparing the files

1.1 On Apache Jenkins

1.2 On your computer once the build described in 1.1 above has succeeded:

1.3 On the NetBeans virtual machine

Producing a Voting Candidate

1. Obtaining and Preparing the Voting Candidate Files

1.1 On Apache Jenkins:

1.2 On your computer, once the build described in 1.1 above has succeeded:

2. Verifying the Release by Checklist

3. Publishing them in the staging area

Create an empty directory for the release then:

Publish to Staging Area

4. Do the vote on the dev mailing list.

5. Creating tag for the Release:

6. Releasing a Release

7. Updating redirect for NetBeans Distribution Update Center

8. Post Release Step

8.1 Git operation post release create PR for snapshot (example for 12.5)

8.2 Git operation post release merge delivery to master

Specific Steps, Details, and Examples

Space shortcuts

Page tree

Apache NetBeans Release README

Overview

Requirements

Branching, builds and release candidate overview.

Preparing the Code Base and Jenkins TLP Job

Taming JSON to Prepare Beta or Voting Candidates

Preparing for beta:

Preparing for voting candidate:

Producing a Release Candidate

1. Obtaining and preparing the files

1.1 On Apache Jenkins

1.2 On your computer once the build described in 1.1 above has succeeded:

1.3 On the NetBeans virtual machine

Producing a Voting Candidate

1. Obtaining and Preparing the Voting Candidate Files

1.1 On Apache Jenkins:

1.2 On your computer, once the build described in 1.1 above has succeeded:

2. Verifying the Release by Checklist

3. Publishing them in the staging area

Create an empty directory for the release then:

Publish to Staging Area

4. Do the vote on the dev mailing list.

5. Creating tag for the Release:

6. Releasing a Release

7. Updating redirect for NetBeans Distribution Update Center

8. Post Release Step

8.1 Git operation post release create PR for snapshot (example for 12.5)

8.2 Git operation post release merge delivery to master

Specific Steps, Details, and Examples