This document describes the overall versioning and sustaining approach to the pkg(5) multi-platform toolkit.

The use of "2.0" as the starting release of the toolkit is mainly due to historical reasons and does not reflect that the binaries in the toolkit are in their second generation of evolution. The pkg(5) system, the Update Tool GUI, desktop notifier, pkg(5) Client Java API, etc are all very much first generation releases. We're starting at "2.0" as the initial release of the toolkit because there was a "1.0" of a similarly positioned "Update Center" feature set delivered in GlassFish v2. Although there is no technology shared between these similar feature sets, we wanted to avoid confusion by referring to both as "1.x".

Release Levels

Sustaining Update Releases

Since we intend to maintain compatibility across minor releases of the toolkit and we want to minimize the overall number of sustaining tails, sustaining updates for a particular minor release will be provided only until the next minor release. Projects using the toolkit and needing important bug fixes will be encouraged to apply the next minor release if it is available. Otherwise, the project will consider producing an update release to address the adopters' bug fix needs.

Promoted Development Builds

Our build numbering is ever increasing across the named major and minor release. Development builds occur every 2-3 weeks and are promoted to the Downloads page and the packages are published to our external developer quality repository at:

http://pkg.sun.com/layered-collection/dev/

Builds and Sustaining Update Releases

Sustaining update releases are made on the branch of the associated minor release. Development builds for an update release continue to use the same build number as the associated minor release but with a different subversion revision number.  For planning purposes, the build is identified with a letter.  For example, the final development build for the 2.2 release was build 30.  The 2 development builds for the 2.2 Update 1 release were called build 30a and 30b for planning purposes, but within the version string and download file names, the build number was still just 30. Normally, each update release is expected to have only a single build.

Package Versions

The pkg-toolkit meta-package, updatetool packageand several other packages follow the versioning scheme described above where "2." is followed by the appropriate minor and update version numbers. The appropriate build number and a more detailed Subversion revision number make up the latter portion of the package version.

<major>.<minor>.<update>-<toolkit build number>.<Subversion revision number>

For example, 2.2 Update 1's updatetool package has the following version number:

2.2.1-30.2210

The core pkg(5) package, pkg, and the companion pkg-java package follow a different versioning scheme for the first portion of the package version. That scheme includes the OpenSolaris build number associated with the version of pkg(5) included in the toolkit.

1.<OpenSolaris build number>.<iteration of the pkg(5) drop>-<toolkit build number>.<Subversion revision number>

Where iteration of the pkg(5) drop represents any rebuilds or temporary private patches the toolkit project might need to apply to the base pkg(5) drop.

For example, the 2.2 Update 1's pkg package has the following version number:

1.111.3-30.2210

Note that the toolkit build number and revision number match those of the updatetool package in the previous example.

Download File Names

The general approach for the naming of toolkit download files available on the Downloads page is as follows:

pkg-toolkit-<version>-<platform>.zip

Where <version> is of the form:

<major>.<minor>.<update> (for releases)
or
<major>.<minor>-b<build> (for development builds)

update being incremented in cases where a set of sustaining fixes is provided for a specific minor release. e.g. 2.0.0 is released and we need to supply fix to it in the form of 2.0.1, aka 2.0 Update 1.

build being the toolkit build number for the pre-release build.

Download File Naming Examples