jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Jackrabbit 1.5 release structure
Date Sun, 12 Oct 2008 15:48:18 GMT

Another related point, I would like to make a minor change to our
version numbering practice: keep the final .z in x.y.z even if it's 0.
Then all our version numbers would follow the same pattern.

This change would make cases like the 1.2.1 release (where we dropped
the 1.2 release candidate due to an issue and created 1.2.1 instead as
the first 1.2.x release) more natural, i.e. the "1.5 release" would
refer to the first release from the 1.5 branch, be it 1.5.0, 1.5.1, or
even 1.5.12 (if we're hopelessly lost with release management :-).

Also, I plan to drop the practice of calling preview builds as release
candidates (as in -rc1, -rc2, etc.). The "release candidate" is the
final build that is being voted for release. Once a release passes,
the release candidate becomes the official release.

The preview builds will instead be labeled with -b1, -b2, etc. These
preview builds are not official releases and should not be published
outside dev@. The purpose of these builds is to enable pre-release
testing and review already before all the issues targeted for a
release have been resolved.

PS. Perhaps we should instead treat the preview builds as official
"beta releases", which would make it easier to distribute them to a
wider audience for increased feedback. However, I'm not sure if that's
worth the trouble of running official release votes.


Jukka Zitting

View raw message