DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
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 be able to connect to https://plugins.netbeans.apache.org as administrator
- 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 (Unknown User (skygo) Unknown User (neilcsmith) Unknown User (lkishalmi) 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.
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!
WIP all in one table
Knowledge
Apache NetBeans version number (2 digit) XX branche name became releaseXX0
| rm machine | repository.apache.org | subversion apache | jenkins | netbeans git | netbeans-jenkins-lib | netbeans antora | plugins site | ||
|---|---|---|---|---|---|---|---|---|---|
| |||||||||
| VOTE NOT PASS go back to LABEL 1 | mail result | ||||||||
| DROP Staging repository | |||||||||
| remove svn | |||||||||
| VOTE PASS RELEASING | mail result | ||||||||
move bits to release area | verify svn updated | ||||||||
| RELEASE repository | |||||||||
| mail announce,anouncenetbeans,users,dev.... | |||||||||
| svn clean old version dist | release note as last release | site donwload page | |||||||
| release date, master and last version | |||||||||
| update redirect doap https://github.com/apache/netbeans-antora/tree/main/supplemental-ui/updates | |||||||||
| remove delivery branch | |||||||||
WIP end
Before freezing:
- 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. Login to https://plugins.netbeans.apache.org and create a new version NetBeans versions
- Announce the feature freeze date on dev@ using [NOTICE] emails a week and a day before branching following up in the same thread - see / adapt example.
After freezing, on the freeze date or shortly thereafter:
- 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 releasexxx branches from master. Announce feature freeze and branching - see / adapt example.
- At the time of branching, update plugin center and update center redirects https://github.com/apache/netbeans-antora/blob/main/supplemental-ui/.htaccess.
- redirect dev and version to current on for RC1
- check site is built
Clone the update center on the NetBeans VM, see also Update centre .htaccess.- 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 forrc1using 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. Build with parameters – '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).
- 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.
- Create a snapshot ( see Prepare Snapshot ) only for RC1
- Send mail to plugin developper
- 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.
- Modify the https://github.com/apache/netbeans/blob/master/.github/ISSUE_TEMPLATE/netbeans_bug_report.yml to have XXX Release Candidate in section label: Apache NetBeans version and XXX-1 in section Did this work correctly in an earlier version?
After the build is complete (weekly, bringing fixes into the delivery branch for the release, syncing them, triggering weekly release candidates):
- 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) Use label release process.
- 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. See also the criteria described at: Pull requests for delivery.
- 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 tonetbeansrelease.json. - Repeat from step 1, 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
deliveryand resync / rebuild.
Moving towards a release 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. - 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
- 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
- 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://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/ (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.
Mail template list
Feature freeze date announce
FreezeAnnounce
[NOTICE]Freeze and branch for Apache NetBeans RELEASENUMBER on DATE Hi All, This is advance notice that we're intending to freeze and branch for NetBeans XXX on DATE. Please help with reviewing remaining pending pull requests. Please be release aware - merged PRs should be ready for release and not require follow up. If in any doubt, push back to NEXTMILESTONE. What we have unmerged for RELEASEMILESTONE is here: https://github.com/apache/netbeans/pulls?q=is%3Aopen+is%3Apr+milestone%3ARELEASEMILESTONE Best Regards
Feature freeze and branching
FreezeAnnounce
[NOTICE] Apache NetBeans RELEASENUMBER feature freeze / release branches Hi All, As per earlier email, the delivery and release branches for NetBeans RELEASENUMBER have now been set up. **Please don't merge to master until the spec version increment is in.** All open pull requests for RELEASEMILESTONE have been pushed to RELEASEMILESTONE+1. If there's a need to get a particular PR into RELEASENUMBER , please rebase on delivery and add the RELEASEMILESTONE milestone. As we now have multiple people doing the release process, there's no need to add us as reviewers - we'll work off the milestone. A first release candidate will be available (all being well) later today. **The following rules are applied to the pull request from now until release:** PR's intended to be included in the RELEASENUMBER release : - Limited to fixes. (no longer need a ticket, but reference issue if there is one) - Label with priority:high or priority:critical as appropriate. - Base on the delivery branch. - Mark with RELEASEMILESTONE milestone. - Will be merged by the release team. - Will be assessed against the bug priority guidelines. PR's with features for a future release : - 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 RELEASENUMBER (delivery will be merged to master weekly). Best Regards
Announce RCXX
Announce RC
[NOTICE] Apache NetBeans RELEASENUMBER release candidate RCN available for testing Hi, The RCN release candidate build for Apache NetBeans RELEASENUMBER is available (links below). Changes since NetBeans RELEASENUMBER-1 / or previous RC can be seen at https://github.com/apache/netbeans/releases/tag/RELEASENUMBER-rcRCN Please help with testing, and file issues in GitHub as necessary - https://github.com/apache/netbeans/issues 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:** Please read the full info on how we manage pull requests to delivery at least once! - https://cwiki.apache.org/confluence/display/NETBEANS/Pull+requests+for+delivery PR's intended to be included in the RELEASENUMBER release : - Limited to fixes (link an issue if there is one, or provide justification in description) - Label with priority:high or priority:critical as appropriate. - Base on the delivery branch. - Mark with RELEASEMILESTONE milestone. - Will be merged by the release team. PR's with features for a future release : - 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 RELEASENUMBER (delivery will be merged to master weekly). The NetBeans RELEASENUMBER-rcRCN artifacts are here: https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/BRANCHNAME/BUILDNUMBER/artifact/dist/netbeans/ Alternative links to latest release candidate: https://nightlies.apache.org/netbeans/candidate/netbeans/ Link to the binary zip: https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/BRANCHNAME/BUILDNUMBER/artifact/dist/netbeans/netbeans-RELEASENUMBER-rcRCN-bin.zip SHA512: <SHA512> The sources are here: https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/BRANCHNAME/BUILDNUMBER/artifact/dist/netbeans/netbeans-RELEASENUMBER-rcRCN-source.zip SHA512: <SHA512> The PRs already integrated into NetBeans RELEASENUMBER are : https://github.com/apache/netbeans/pulls?q=is%3Amerged+milestone%3ARELEASEMILESTONE Issues currently tagged for NetBeans RELEASENUMBER are : https://github.com/apache/netbeans/issues?q=is%3Aopen+is%3Aissue+milestone%3ARELEASEMILESTONE Release schedule : https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule Thank you for your contributions and review! Best Regards,
Mail for vote
Mail for vote
[VOTE] Release Apache NetBeans XX This is our first voting candidate for the release of Apache NetBeans XX. Please follow the voting template at the bottom of this email, and note all requirements below for validating sources and convenience binaries before voting. Apache NetBeans XX constitutes all clusters in the Apache NetBeans Git repository, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache NetBeans. ------------------------ Build artefacts are available here : https://dist.apache.org/repos/dist/dev/netbeans/netbeans/XX/ They were built by the Jenkins pipeline : https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/releaseXXX/buildnumber/ ------------------------ We are primarily voting on : https://dist.apache.org/repos/dist/dev/netbeans/netbeans/XX/netbeans-XX-source.zip SHA512 : <> KEYS file : https://downloads.apache.org/netbeans/KEYS ------------------------ Associated with the primary source item we have, generated with the pipeline above : Binary zip - https://dist.apache.org/repos/dist/dev/netbeans/netbeans/XX/netbeans-XX-bin.zip SHA512: <> ------------------------ Maven Artefacts The Maven artefacts for Apache NetBeans XXare ready on staging associated to this vote. https://repository.apache.org/content/repositories/orgapachenetbeans-YYYY/ The version is : RELEASEXXX ------------------------ Voting requirements Before voting +1 you are required to download the signed source code package, compile it as provided, and test the resulting executable on your own platform, along with also verifying that the package meets the requirements of the ASF policy on releases - https://www.apache.org/legal/release-policy.html#management In particular, you should (at least) follow these steps. 1. Download the artefact to be voted on and unzip it. 2. Check that the artefact does not contain any jar files (there are branding folders with the name *.jar). 3. Verify the cryptographic signatures, the NOTICE and LICENSE file 4. Build it using the README provided by the artefact. 5. Look in nbbuild/netbeans for the NetBeans installation created by the build process and try running it. In addition to checking the sources, you may check the associated convenience binary zip and maven staging at the links above. You are not expected to check every convenience binary. As well as checking any artefact functions correctly, you should check that it has been correctly signed by a PMC member, and that the source being voted on is sufficient to build the relevant binary. This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as usual. (Please justify -1) Please mark your vote with (binding) only if you're an Apache NetBeans PMC member to help with voting admin. Only respond if you are going to vote, i.e., this is NOT a discussion thread. Apache NetBeans XX will be released if and when this vote passes. ----------------------- Voting template Please copy and paste the answer pattern below into your email. Fill the checkboxes as appropriate (eg. [X]). Replace <OS>, <JDK> and <TYPE> as appropriate. -- Answer pattern ------------------------ [ ] yes / +1 [ ] no / -1 (please justify -1) [ ] binding (member of PMC) My vote is based on [ ] I have built and tested the source with <JDK> on <OS> (required) [ ] I have tested the binary zip with <JDK> on <OS> [ ] I have tested the Maven artefacts --------------------------- Thank you to all contributors for all your hard work! Best Regards Eric
Actions templates
Create a tag on git repo
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
Prepare sigtest
Snapshot generation
# checkout branch (or release tag)
git checkout releaseXXX
git clean -dxf
ant build
ant gen-sigtests-release
git add -A
git stash
git checkout master
git checkout -b apis-nbxx+1
git stash pop
git add -A
git commit -m "Snapshot of APIS as of NetBeans XX"
# remove getPeer() calls
find . -name "*.sig" -exec sed -i '/java.awt.peer.ComponentPeer/{N;d;}' {} \;
# check git diff
git add -A
git commit --amend
Sign source/bin
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 {} \;
Sign maven artefacts
export GPG_EMAIL="YOU@apache.org"
find . \( -name '*.nbm' -o -name '*.xml' -o -name '*.pom' -o -name '*.sha1' -o -name "*.md5" -o -name "*.jar" \) -exec gpg -u $GPG_EMAIL --armor --output {}.asc --detach-sig {} \;
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://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/
- 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**
2. Notifications to mailing list
- Send a mail to netcat and dev mailing lists.
3. Workflow
- Repeat Release Candidate until consensus is reached
- If consensus to release is reached you can produce a Voting Candidate
Producing a Voting Candidate
Producing a voting is close to producing a release candidate. Branding will change to match release branding. You will have to sign all artefacts
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://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/
- 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; doneSign 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:
- Start NetBeans with an empty User directory
- Open a Java SE project: installing nb-javac shall present GPL
- Start NetBeans with an empty User directory
- 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.
Note 3: dev/netbeans folder a script testrelease.sh check for sha512 on all the subfolder + signature (never move this script to release)
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/ ## On branching to releaseXXX mkdir $VERSION cd $VERSION/ copy .htacces from ../($VERSION-1) ## RC Stage: vim .htacces # and uncomment first block update link to jenkins job and comment others ## Release State (Once voted) curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/$VERSION/nbms/updates.xml.gz -o updates.xml.gz curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/$VERSION/nbms/updates.xml.gz.asc -o updates.xml.gz.asc curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/$VERSION/nbms/updates.xml.gz.sha512 -o updates.xml.gz.sha512 curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/$VERSION/nbms/updates.xml -o updates.xml curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/$VERSION/nbms/updates.xml.asc -o updates.xml.asc curl https://dist.apache.org/repos/dist/release/netbeans/netbeans/$VERSION/nbms/updates.xml.sha512 -o updates.xml.sha512 vim .htacces # and uncomment Release State block and verify version and comment others cd /var/www/html/uc/($VERSION-1)/ vim .htacces # and uncomment Archive state block and verify version and comment others on a few version back cd /var/www/html/uc/($VERSION-n)/ # n from 1 to what you want vim updates.xml.gz vim updates.xml #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/ ##cho '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 $VERSION 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 --amen8.2 Git operation post release merge delivery to master
(wip)
website
on antora-site
PR for download page, do not announce,
PR for blogs entry
on antora-ui
PR for banner merge after a links are ok
mail to + X
In the mail for announce put a section for presenting NetBeans
mail to announce@apache.org
mail to announce@netbeans.apache.org
mail to dev@netbeans.apache.org
mail to users@netbeans.apache.org
--
clean up old release on dist,, 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