- Announce to the nss-dev mailing list that a release is coming
- Make sure you are in possession of an SSH account at Mozilla's staging server for FTP, and that your user account is a member of group "security".
- Check with people on the list what the minimum required NSPR release number should be for this NSS release. Coordinate with NSPR developers that this NSPR release is ready by the time you create the NSS release.
- Announce when the repository shall be frozen, so you can proceed with the release without disturbances
- Update the status message on the tinderbox page to make people aware that the tree is frozen and that people should coordinate any checkins with the nss-dev mailing list.
- check out the latest code, for exampling using
cvs -z3 -q co mozilla/security/nss mozilla/security/coreconf mozilla/security/dbm mozilla/dbm
- ensure your local tree doesn't have any local changes
- make sure nobody else has checked in unexpected code (for example by using the link to the recent checkins on the tinderbox page)
- The version numbers in the source code mention "Beta", both as a string and as a boolean value. Carefully change the version numbers to final release, exactly as shown in the following illustrative patch (but of course using the appropriate numbers).
see attachment called p-release (will create soon)
- run cvs diff after changing the beta versions to ensure your happy with the changes
cvs -z3 -q diff -u security/nss security/coreconf security/dbm dbm
- Commit the change to cvs (If you have permission from the NSS development team to create the release, you don't need separate permission to check in this change.)
- The code you have created is the first release candidate. The 4th number in NSS version numbers is the release candidate number. The first release candidate has number zero.
- Create a release candidate tag, as a static tag. It should follow the style "NSS_3_13_3_RC0". The final number should be the same number as in the version number. To create the tag use this command:
cd mozilla
cvs tag NSS_3_13_3_RC0 dbm security/dbm security/coreconf security/nss
- Proceed to test the tag, for example by landing it into Mozilla. See also: Updating NSPR or NSS in mozilla-central
- If additional changes are necessary, increase the release candidate number in all files, commit your change, create a new release candidate tag, etc.
- Once the decision is made that your release candidate is indeed the final release, create the release tag, such as NSS_3_13_3_RTM
- Update https://wiki.mozilla.org/NSS:Tags to mention the new tag
- Prepare cvs for development of the next version, by increasing all version numbers, resetting release candidate number to zero, and adding back the "Beta" information, exactly as shown in the following illustrative patch
see attachment called p-beta (will create soon)
- Announce the creation of the release tag to the nss-dev mailing list.
- Create a new local directory for preparing the release tar archives and cd to it, for example
mkdir 3133rtm
cd 3133rtm
- Create another directory named after the version number, for example
mkdir nss-3.13.3
cd nss-3.13.3
- Use the release tag to export the code, and afterwards go up one level
cvs -z3 export -r NSS_3_13_3_RTM mozilla/dbm mozilla/security/nss mozilla/security/coreconf mozilla/security/dbm
cd ..
- Create a tar archive (we still use old gzip for maximum compatibility with consumers):
tar czvf nss-3.13.3.tar.gz nss-3.13.3
- Multiple consuming projects have asked us to provide combined tar archives that contain both NSS and the corresponding minimum NSPR version that it requires. Get that NSPR version, for example by exporting the tag from CVS:
cvs -z3 export -r NSPR_4_9_RTM mozilla/nsprpub
- Move nsprpub into your NSS tree:
mv -i your-temporary-directory-for-nspr/mozilla/nsprpub nss-3.13.3/mozilla/
- verify that nss-3.13.3/mozilla contains 3 directories: dbm + nsprpub + security
ls -l nss-3.13.3/mozilla
- Create the combined tar archive:
tar czvf nss-3.13.3-with-nspr-4.9.tar.gz nss-3.13.3
- create MD5SUMS and SHA1SUMS files:
md5sum *.gz > MD5SUMS
sha1sum *.gz > SHA1SUMS
- prepare the directory hierarchy that will be used on the FTP server, move the files into it, and copy the directory to the staging server
mkdir -p NSS_3_13_3_RTM/src
mv -i *.tar.gz *SUMS NSS_3_13_3_RTM/src
scp -pr NSS_3_13_3_RTM user@stagingserver.mozilla:
- Now connect to the shell on the staging server for final preparations of the files, change the group ownership, set the right persmissions, and finally move them to the right place
ssh user@stagingserver.mozilla
chgrp -R security NSS_3_13_3_RTM
chmod -R g+w NSS_3_13_3_RTM
- ensure that everything looks correct with both user and group readable/writeable, world readable, directories also executable, and all groups set to security.
$ ls -ld NSS_3_13_3_RTM
drwxrwxr-x 3 kaie security 4096 Feb 22 01:50 NSS_3_13_3_RTM
$ ls -l NSS_3_13_3_RTM
drwxrwxr-x 2 kaie security 4096 Feb 22 01:50 src
$ ls -l NSS_3_13_3_RTM/src
-rw-rw-r-- 1 kaie security 118 Feb 22 01:49 MD5SUMS
-rw-rw-r-- 1 kaie security 6083507 Feb 22 01:47 nss-3.13.3.tar.gz
-rw-rw-r-- 1 kaie security 7295947 Feb 22 01:49 nss-3.13.3-with-nspr-4.9.tar.gz
-rw-rw-r-- 1 kaie security 134 Feb 22 01:49 SHA1SUMS
- check that the publishing area still exists at the expected position
ls -l /home/ftp/pub/security/nss/releases/
- you're ready to publish, move the directory from your home directory to the publishing area:
mv -iv NSS_3_13_3_RTM /home/ftp/pub/security/nss/releases/
- Shortly afterwards the new directory should appear in the NSS releases FTP directory
- Announce the availability of the new release to the mozilla-dev-tech-crypto list, with a link to FTP and potentially with release notes.