JBoss Product Version Conventions

Product versions follow this format X.YY.ZZ.Q (i.e. 1.2.3.GA, 1.2.3.CR1, 1.2.3.Alpha1-20060205091502)

X signifies major version related to production release. This is a number.

YY signifies minor version with minor feature changes or additions. This is a number.

ZZ signifies patches and bug fixes. Minor features that do not introduce backward compatibility issues are ok. This is a number.

Q is an alpha-numeric qualifier. The prefix of the qualifier needs to match the qualifier conventions listed below to ensure that versions can be compared consistently in terms of version ordering.

Major versions are usually developed in multiple iterations. Each iteration concludes with an intermediate version release. Intermediate versions are annotated with appropriate suffixes. This shows the progression of release versions. A given release may not have all stages of releases shown here.

Current Qualifier Conventions (Post 2006-03-01)

The following version conventions were put in place to have interop with eclipse/OSGI bundle version conventions.

1. X.Y.ZZ.SNAPSHOT - The current snapshot from the X.Y.ZZ development branch. The stability of such a release is completely unknown as unlike other releases, the content of the release can change without a corresponding change in the version. Nightly builds of the current branch would be an example. Also, there can be no public release other than a snapshot release that declares itself to be compatible with another snapshot as this is a nonsensical, untested dependency on unstable code.

2. X.Y.ZZ.Alpha - An Alpha release includes all key features and is passing the main test cases. It still needs work on edge cases, bug fixes, performance tuning and other optimization tasks.

3. X.Y.ZZ.Beta - A Beta release is the first release that the development and QA teams feel comfortable releasing for public testing. Some bug fixes and minor optimizations are expected, but no significant refactoring should occur. No new major features are introduced from this phase on. Only stabilizing work.

4. X.Y.ZZ.CR - Each CR (Candidate Release) is a potential target for final release. Only if unexpected bugs are reported during the iteration time frame, the RC number is incremented (e.g. jboss-4.0.4.CR1 to jboss-4.0.4.CR2), and another release candidate is published. Generally only minor bug fixes are introduced to code and documentation.

5. X.Y.ZZ.GA - A GA (General Availability), or Final, version is released when there are no outstanding issues from the last CR version. Usually it's a matter of renaming the version from CR to GA and repackaging the software (e.g. jboss-4.0.4.GA).

6. X.Y.ZZ.SP - An SP (Service Pack) may follow a final release. A service pack (e.g. jboss-4.0.3.SP1) may be released when there are significant issues found after a final release to provide a bug fix release before the next scheduled final release.

Practices

The standard qualifiers are the required prefixes. Additional information may be included in the qualifier as a suffix to incorporate information such as the build id to allow for distinction between nightly builds for example. If a given branch of a project is at 1.2.3.Beta1, the full version used could include a build id based on a GMT timestamp, the actual number of builds, etc. using a full qualifier syntax like Beta1-NNN where NNN is the numeric build id.

The key thing is that all version usage be consistent for a given project. A project cannot include a build id in the nightly builds, and then fail to include a build id of greater value when 1.2.3.Beta1 is actually released. The reason is that 1.2.3.Beta1 cannot be seen to be older than some previous 1.2.3.Beta1-NNN nightly build. Similarly, case of the qualifiers must be consistent as the version comparison code my use case sensitive comparison (OSGI does).

Jar Manifest Headers

To be defined. The standard Java version information and OSGI bundle version headers and their usage needs to be defined. The standard Java jar manifest headers should include:

Manifest-Version: 1.0
Created-By: @java.vm.version@ (@java.vm.vendor@)
Specification-Title: @specification.title@
Specification-Version: @specification.version@
Specification-Vendor: @specification.vendor@
Implementation-Title: @implementation.title@
Implementation-URL: @implementation.url@
Implementation-Version: @implementation.version@
Implementation-Vendor: @implementation.vendor@
Implementation-Vendor-Id: @implementation.vendor.id@

where:

• Specification-Title: whatever name/standard name the jar implements

• Specification-Version: the version number

• Specification-Vendor: JBoss (http://www.jboss.org/)

• Implementation-Title: name with additional implementation details

• Implementation-URL: http://www.jboss.org/

• Implementation-Version: a full implementation version with addition build info. For example: ${version.major}.${version.minor}.${version.revision}.${version.tag} (build: CVSTag=${version.cvstag} date=${build.id})

• Implementation-Vendor: JBoss Inc.

• Implementation-Vendor-Id: http://www.jboss.org/

Legacy Qualifier Conventions (Pre 2006-03-01)

1. X.Y.ZZ DR - DR stands for Development Release. There could be a number of development releases (e.g. jboss-4.0.0DR1). A development release is a significant project milestone, but it does not implement all of the key features targeted for the public release.

2. X.Y.ZZ Alpha - An Alpha release includes all key features and is passing the main test cases. It still needs work on edge cases, bug fixes, performance tuning and other optimization tasks.

3. X.Y.ZZ Beta - A Beta release is the first release that the development and QA teams feel comfortable releasing for public testing. Some bug fixes and minor optimizations are expected, but no significant refactoring should occur. No new major features are introduced from this phase on. Only stabilizing work.

4. X.Y.ZZ RC - RC stands for Release Candidate. Each release candidate is a potential target for final release. Only if unexpected bugs are reported during the iteration time frame the RC number is incremented (e.g. jboss-4.0.1RC1 to jboss-4.0.1RC2) and another release candidate is published. Generally only minor bug fixes are introduced to code and documentation.

5. X.Y.ZZ Final - A Final version is released when there are no outstanding issues from the last RC version. Usually it's a matter of renaming the version from RC to Final and repackaging the software (e.g. jboss-4.0.1).

6. X.Y.ZZ SP - SP stands for Service Pack. A service pack may be released when there are significant issues found after a final release to provide a bug fix release before the next scheduled final release.

Roadmaps are in Jira

The roadmaps for the JBoss projects are found on the JBoss JIRA site http://jira.jboss.com/.

Related

JBoss OIDs

Referenced by: