NetBSD is available in three forms: Formal release - tested, production version. Maintenance branches - various maintenance branches. NetBSD-current - feature (development) tree. Additionally, there is a graph showing an overview of release branches, depicting the 3.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 2.0 or 3.0, of a maintenance (stable) release such as 2.1, or a security/critical release like 2.0.2. 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. 2.1. A minor release is generally more reliable than -current of the same date, but is missing features compared to -current. NetBSD has with the release of NetBSD 2.0 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 Starting with NetBSD 2.0, maintenance branches come in two flavours: 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. 2.0_STABLE, which will evolve into 2.1. 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. 3.1 to 3.1.1. Versions in between used to be called e.g. 2.0.0_STABLE, but since the NetBSD 3.0.2 and 3.1 releases they are called e.g. 3.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 3.0, the CVS branch for it is "netbsd-3" which can be thought of as containing an alpha version of the following 3.x releases. The security/critical branches only receive 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 2.0, the CVS tag for the corresponding security/critical branch is "netbsd-2-0", and will give rise to 2.0.1 and any following 2.0.x security/critical releases. The maintenance branch(es) can be considered an easy way to get the most up to date fixes for a given release. There are daily updated snapshots of the latest maintenance branches, available via both CVS, FTP and SUP. The directories pub/NetBSD/NetBSD-release-3-0/ and pub/NetBSD/NetBSD-release-2-0/ contain the extracted sources plus weekly updated tar files of both the 3.0 and 2.0 release branches respectively. These files are created in a similar manner to those in the /pub/NetBSD/NetBSD-current directory. NetBSD-current 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. 3.99.23 will eventually become 4.0_BETA (and later, 4.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. NetBSD-current is available via SUP, CVS, cvsweb, and FTP. You should be aware that in BSD CSRG terms, -current is normally an alpha quality distribution. It isn't even guaranteed to compile. Snapshots Binary snapshots of the latest release branch and -current are available from . 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.