Version Numbers

Added in 5.3
Tapestry version numbering was change starting in release 5.3. Tapestry 5.2 and earlier used a different numbering scheme whose primary failing was that, from the version number, it was not obvious what the stability of the version was.
This document describes Tapestry's version numbering system. This is important, as version numbers relate both to artifacts available for download, or from a Maven repository, and also to bugs recorded in the issue tracking system.

Tapestry Release Numbers

Tapestry release numbers consist of a product version number, and release index number, seperated by periods, for example "5.3". The product version number, 5, is unlikely to change any time soon (it would indicate a non-backwards compatible rewrite of the framework, and we've had enough of that, thank you very much).

Tapestry Stable Release Versions

Tapestry stable releases use the name version number as the release number.

A bug fix release follows a stable release, when necessary. Bug fix releases add a sequence number to the product release number. Thus, the first bug fix release for Tapestry 5.3 will be version 5.3.1, then 5.3.2, as necessary.

A bug fix release replaces the previous stable release.

Preview Versions

During the course of development of a release, there will be preview releases of non-final versions. A preview version consists of the product version, a stability term, and an index number, separated by dashes. The stability term is "alpha", "beta", or "rc".

The index number starts at 1. A preview version number might be "5.3-alpha-2", or "5.3-beta-1", for example. The index number resets back to one when the stability itself is upgraded.

"alpha" versions are not stable; the represent functionality in flux; classes and methods may be renamed or otherwise refactored between releases.

"beta" versions occur once main functionality is complete; they exist to fix bugs in both old and new functionality, and fill any gaps in functionality.

"rc" versions are "release candidates"; the functionality should be solid; the point of a release candidate is to get wide exposure to the new codebase to ensure that the final release is free of bugs.

Preview Packages

A preview package may be created at any time. A tag is created in Git to label the exact source from which the preview package is generated. The preview package is built and uploaded to the Apache Nexus. Once uploaded, the master version number (in trunk) should be advanced to the next index number within the same stability series (example: "5.3-alpha-2" to "5.3-alpha-3").

The Apache Nexus URL for the preview package may be distributed on the Tapestry user mailing list. However, preview packages are deleted, not released. This is important ... preview packages are never released to the Maven Central repository, only final releases are distributed via Maven Central.

A stability vote may follow a preview package. This is to vote the code base up to the next level of stability (to "beta", then "rc", then "stable"). This a lazy consensus vote.

Stable Releases

Once a version has been voted "stable", a release may be built and uploaded to the Apache Nexus. A stable release also includes additional non-Maven artifacts containing the project's source code, and additional artifacts containing JavaDoc or other reports. The other artifacts are distributed via the Apache Mirrors.

The vote for a release is a binding vote, requiring at least 3 +1 votes and no vetoes, as outlined in

Following a successful release vote, the final release artifacts in the Apache Nexus repository may be released to the Maven Central repository, and the additional artifacts moved into place for download from the Apache distribution mirrors. This is also the point at which the Tapestry wiki is updated to announce the new release (and provide proper links to it), as well as announcements on the Tapestry user mailing list and elsewhere.

Bug fix releases are follow-ons to stable releases. Bug fix versions automatically start at stability "rc", reflecting the fact that only localized bug fixes are expected to be included in such a release. Once all desired bug fixes are in place, a stability vote (to "stable") is followed by a release vote.