NetBSD Developer Documentation: The Release Engineering Process

NetBSD Developer Documentation: Release Engineering: The Release Engineering Process

4.4 How to make a NetBSD release

4.4.1 Overview

The NetBSD Release process is an eight week process which is intended to make it possible to generate frequent quality releases without stalling development on the main branch. The goal is to have two NetBSD releases per year.

In the description below, VERSION can have different textual representations depending on context. For instance, if describing the release of NetBSD 1.2, VERSION would be "1-2" when used in a CVS command, "1.2" when talking about the version as announced to the public or defined in src/sys/conf/newvers.sh, or "1_2" when talking about the definition of the NetBSDVERSION constant in src/sys/sys/param.h.

The basic timeline for a release looks like:

Week 0: Beginning of release cycle: The release schedule is sent as a reminder to all NetBSD developers and mirror maintainers.
Week 1: Snapshot sanity check: Port maintainers should try to build full releases, to ensure that the release generation machinery is functional.
Week 2: Creation of release branch and feature freeze: The release branch is created, and developers are disallowed from committing new features to the release branch without permission from the Release Engineer.
Week 3: First beta release: Binary snapshots are released as NetBSD VERSION_ALPHA.
Week 4: Non-critical bug fix freeze: Developers are disallowed from committing any changes other than critical bug fixes to the release branch without permission from the Release Engineer. Mid-week, the release branch is tagged netbsd-VERSION-BETA.
Week 5: Second beta release: Binary snapshots are released as NetBSD VERSION_BETA.
Week 6: Code freeze: Developers are disallowed from committing ANY changes to the release branch without permission from the Release Engineer.
Week 7: Tag final sources: The release branch is tagged netbsd-VERSION-FINAL, and port maintainers begin generating final release binaries.
Week 8: Release: The release is announced to the world.

Yet to be done in this document:

Fill in various details. (Search for XXX.)
General background; note existence of "Release Engineer," his/her responsibilities, expand notion that development continues as normal on trunk, etc.
More details on release branch management: procedure for pulling changes up, procedure for getting approval for changes, etc.
Post-release patching. (It may make sense to re-work the various "NetBSD" definitions in src/sys/sys/param.h in light of post-release patches.)

4.4.2 Week 0: Beginning of release cycle

Dates should be set for the various events in the release cycle
The updated release cycle calendar should be sent as a reminder to NetBSD developers (developers@NetBSD.org) and mirror maintainers (XXX DETAILS).

4.4.3 Week 1: Snapshot sanity check

Port maintainers should try to build full releases, to ensure that the release generation machinery is functional.

4.4.4 Week 2: Creation of release branch and feature freeze

Update doc-operating-system in src/gnu/usr.bin/groff/tmac to the version to be released. Add an appropriate doc-operating-system-NetBSD-X.Y line too, if it's not there yet (contact wiz@NetBSD.org in case of questions).
Tag the base of the release branch with a command like:
```
cvs rtag -a netbsd-VERSION-base src
```

Create the release branch with a command like:

cvs rtag -a -b -rnetbsd-VERSION-base netbsd-VERSION src

On the trunk, do the following:
- Update the NetBSD constant in src/sys/sys/param.h to be a date soon after the final release is expected.
- Update the NetBSDVERSION constant in src/sys/sys/param.h so that it uses the appropriate major and minor version numbers, and is defined to "2" (to indicate NetBSD-current, after the release).
- Update osr in src/sys/conf/newvers.sh to indicate the proper release with an "A" suffix (to indicate NetBSD-current, after the release).
- Update send-pr. (XXX HOW?)
On the release branch, do the following:
- Update the NetBSD constant in src/sys/sys/param.h to be the date of the expected "ALPHA" distributions.
- Update the NetBSDVERSION constant in src/sys/sys/param.h so that it uses the appropriate major and minor version numbers, and is defined to "1" (to indicate the appropriate formal release.)
- Update osr in src/sys/conf/newvers.sh to indicate the proper release with an "_ALPHA" suffix.
- Update send-pr. (XXX HOW?)
Change FTP/SUP service on ftp.NetBSD.org and sup.NetBSD.org to distribute the release branch.
Announce to the world the fact that the release process is underway. Note that FTP and SUP service will be distributing the release branch during the release process.
Notify developers of release branch creation. Include procedure for accessing branch and notification that they should not be committing new features to the branch without permission of the Release Engineer.
Update the release web page with the expected and actual dates.
Create SUP collections for the new release. (XXX DETAILS?)
Notify mirror maintainers about the new SUP collections, so that they can start supping them before beta distributions show up.

4.4.5 Week 3: First beta release

Port maintainers should create and distribute binary snapshots, labeled NetBSD VERSION_ALPHA.
Announce the alpha release to the world via the netbsd-announce@NetBSD.org mailing list and comp.unix.bsd.netbsd.announce newsgroup. (???)

4.4.6 Week 4: Non-critical bug fix freeze

At the beginning of the week:

Notify developers that they should not check in any changes to the release branch without permission from the Release Engineer other than critical bug fixes.

At mid-week:

Update NetBSD in src/sys/sys/param.h, osr in src/sys/conf/newvers.sh, and send-pr as detailed in the description for Week 2, except using values appropriate for the "BETA" release.

Tag the sources "beta," with a command like:

cvs rtag -a -rnetbsd-VERSION netbsd-VERSION-BETA src

Instruct port maintainers to begin generating the beta release.

4.4.7 Week 5: Second beta release

Beta binaries are released as NetBSD VERSION_BETA.
Announce the beta release to the world via the netbsd-announce@NetBSD.org mailing list and comp.unix.bsd.netbsd.announce newsgroup.

4.4.8 Week 6: Code freeze

At the beginning of the week:

Notify developers that they should not check in any further changes to the release branch without permission from the Release Engineer.

At mid-week:

Update NetBSD in src/sys/sys/param.h, osr in src/sys/conf/newvers.sh, and send-pr as detailed in the description for Week 2, except using values appropriate for the "FINAL" release.

4.4.9 Week 7: Tag final sources

At mid-week:

Tag the sources "final," with a command like:

cvs rtag -a -rnetbsd-VERSION netbsd-VERSION-RELEASE src

Instruct port maintainers to begin generating the final release.

4.4.10 Week 8: Release

Final binaries are released as NetBSD VERSION.
Notify SUP and FTP mirror maintainers, so that they can update their sites.
Update bsd-family-tree

Two days later:

Announce the release to the world via the netbsd-announce@NetBSD.org mailing list and comp.unix.bsd.netbsd.announce newsgroup.

Home Page

Developer Documentation