NetBSD release glossary and graphs
NetBSD is available in three forms:
Additionally, there is a graph showing an overview of release branches, depicting the 6.0 release and the following maintenance branches as an example.
NetBSD has recently changed the release numbering scheme. For completeness, there is also a section which describes the old release numbering scheme.
- Formal release
An official, believed to be reliable, source and binary distribution of NetBSD. This can either be in the form of a major release like 5.0 or 6.0, of a minor release (sometimes referred to as "maintenance" or "stable") such as 5.2, or a security/critical release (sometimes referred to as "teeny") like 5.1.3.
For each major release there is a corresponding maintenance branch, and after the release of the major release, bug fixes and features with limited scope are ported back to the maintenance (stable) branch. This maintenance branch will after a while give rise to formal minor releases, e.g. 6.1. A minor release is generally more reliable than -current of the same date, but is missing features compared to -current.
With the release of NetBSD 2.0 years ago, NetBSD introduced the concept of security/critical releases. These are created from CVS branches which are branched off the release points for major and minor releases. These particular maintenance branches only receive bug fixes which either fix security problems or other critical problems. This is illustrated in the graph showing the release branches.
- Maintenance branches
Maintenance branches come in two flavors:
- Maintenance branches which will develop into the next minor release, which we call stable branches, and which is reflected in the version designation along this branch, e.g. 6.1_STABLE, which will evolve into 6.2. The corresponding CVS branch is the same branch that was created from NetBSD-current and which gave rise to the corresponding previous major release.
- Maintenance branches which will give rise to any security/critical release. These are created from each major and minor release. This is what we refer to as the security/critical branches. Because the interval between application of fixes and the tagging of the corresponding release, there is no separate "branch version designation" for these branches, instead the version number will jump from e.g. 6.1 to 6.1.1. Versions in between are called e.g. 6.1.0_PATCH, to distinguish them more clearly from the above mentioned stable branches.
What you will find on a stable branch is the last release (major or minor) plus whatever bug fixes and enhancements which will be going into the next minor release, pulled up from the NetBSD-current development branch. For example, if the latest release is 6.0, the CVS branch for it is "netbsd-6" which will give rise to 6.1 and any following 6.x releases.
What you will find on a security/critical branch is a major or minor release plus select fixes for security problems or other critical problems. The aim is to provide such fixes but at the same time minimize the set of other changes which would otherwise get dragged in if one were to update along a stable branch. For example, if the latest release is 6.0, the CVS tag for the corresponding security/critical branch is "netbsd-6-0", and will give rise to 6.0.1 and any following 6.0.x security/critical releases.
The maintenance branches can be considered an easy way to get the most up-to-date fixes for a given release. Many users will be well-served following these branches.
There are daily updated snapshots of the latest stable branches, available via both CVS, FTP and SUP. The directories pub/NetBSD/NetBSD-release-6/ and pub/NetBSD/NetBSD-release-5/ contain the extracted sources plus weekly updated tar files of both the "netbsd-6" and "netbsd-5" stable branches, respectively. These files are created in a similar manner to those in the /pub/NetBSD/NetBSD-current directory.
NetBSD-current is the main development branch of NetBSD, it's the "bleeding edge" of NetBSD development. The version number is always in the form of N.99.M, and will develop into the next formal major release. E.g. 6.99.23 will eventually become 7.0_BETA (and later, 7.0). In NetBSD-current, the last component in the kernel's version number is incremented when one of the major interfaces in the kernel or between the kernel and userland is changed.
You should be aware that in BSD CSRG terms, -current is normally an alpha quality distribution. It isn't even guaranteed to compile.
Binary snapshots of the latest release branch and -current are available from http://nyftp.NetBSD.org/pub/NetBSD-daily/.
Ad-hoc snapshots may also be made by a port maintainer and can be of NetBSD-current or maintenance branches. Usually the easiest way to start tracking -current is by installing a recent snapshot.
Up until the NetBSD 2.0 release, we used a slightly different release numbering scheme. In that scheme, the major releases were numbered as 1.5 and 1.6, and the minor releases were numbered as 1.4.3 and 1.6.2. The version designations for NetBSD-current would be formed by the previous major version and one or two letters, such as 1.6B or 1.6ZA.
The following figure illustrates the relationship between the earlier NetBSD releases and the CVS branch names and CVS tags.
Lastly, an additional complication and deviation from the above rules is worth mentioning for completeness (and it also shows in the old release branch graph above), and that is that even though the change in release and CVS branch naming was done prior to the final release of 2.0, it was done after the point where the release branch for the release was created. Thus, the initial branch tag for the 2.0 release was netbsd-2-0, and not netbsd-2, as it should have been under the new scheme. However, the branch names following the release of 2.0 are adhering to the new rules, i.e. the branch leading up to 2.0.1 is netbsd-2-0 and the branch which will lead up to 2.1 is netbsd-2.