Chapter 17. Project Release Procedures

This section describes the JBoss Project Release procedure.

17.1. Tagging Standards

Tags on JBoss projects should consist of two parts - project
identifier and version number. A list of existing modules
can be found on the
CVS Modules
page. The version number must follow
JBoss Versioning Conventions
. A correctly tagged project would be JBoss_4_0_2, which is
the tag for the JBoss Application Server, version 4.0.2.
Note that all '.' from the version have been replaced with
'_'.

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

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.

17.2.1.
Current Qualifier Conventions (Post 2006-03-01)

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

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.

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.

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

X.Y.ZZ.GA - A 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 Final and repackaging the
software.

X.Y.ZZ.SP# - A service pack release to a final
release. A service pack may be made when there
are significant issues found after a final
release to provide a bug fix release before the
next scheduled final release.

17.2.2. Practices

The standard qualifiers are the required prefixes.
Additional information may be included in the qualifer
as a suffix to incorprate 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.

17.2.3. Legacy Qualifier Conventions (Pre 2006-03-01)

X.Y.ZZ.DR# - DR stands for Development Release.
There could be a number of development releases.
For example 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.

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.

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.

X.Y.ZZ.RC# - Each release candidate is a
potential target for final release. Only if
unexpected bugs are reported during the
iteration timeframe 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.

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 (jboss-4.0.1).

X.Y.ZZ.SP# - A service pack release to a final
release. A service pack may be made when there
are significant issues found after a final
release to provide a bug fix release before the
next scheduled final release.

17.3. JBoss Naming Conventions

17.3.1. Naming of Build Artifacts

When creating jars as a result of a project's build, do
not include the version element in the jar name. An
example of that would be the current JBoss Messaging
component of the Application Server - jbossmq.jar and
not jbossmq-1.1.jar

17.3.2. Jar Manifest Headers

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:

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})

The binary outputs for the project should be built
and added to the repository

MD5 checksums should be generated for the binary
outputs of the project

The testsuite should be able to run with a 100%
success rate

Create a JBQA issue in JIRA for coordination with QA

Once all items on the Pre-Release Checklist have been
completed, the project is ready for release testing.

17.5. QA Release Process

When a project is ready for a release and the
Pre-Release Checklist
has been completed, the QA team follows a standard release
procedure outlined below.

2 weeks prior to release the project team should
open a JIRA issue in the JBoss QA project detailing
what will be released, the date it is expected to be
released on, and the CVS tag which will be used for
the release

On release day the team will tag their project
appropriately and enter a comment on the JIRA issue
notifying QA that the project is now ready for the
QA process.

QA team checks out the project and any dependent
modules from cvs by the specified tag

QA team then builds the project using the target
distr from the build script

QA team will then run the testsuite for the specific
project and analyze their results - if any failures
are present those issues need to be resolved by the
QA or project teams before the release process could
resume

QA team will verify documentation is present and
correct

After all tests are passing, QA team will upload the
disctribution archives

QA team makes a release on Sourceforge.net and a
binary release to jboss-head