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: 1.0 release plan (Was: time for another incubator board report)
Date Mon, 16 Jan 2006 21:41:02 GMT

On 1/15/06, Roy T. Fielding <fielding@gbiv.com> wrote:
> Yes, though I actually meant that we need to document what the versions
> mean so that we all agree.  For example
>      http://apr.apache.org/versioning.html

My opinion would be to use a similar MAJOR.MINOR.PATCH versioning
scheme with the following semantics:

MAJOR versions are based on the JCR API version. Jackrabbit 1.x
implements the JSR 170 API and a future Jackrabbit 2.x will implement
the JSR 283 API. It is likely that some or even all of the
Jackrabbit-specific JCR extensions and underlying component interfaces
will be changed when a MAJOR version is made.

MINOR versions will all use the same JCR API and will thus be binary
compatible for pure JCR clients. It is possible for MINOR versions to
introduce new features and deprecate existing ones as long as the JCR
API is not touched. It would even be possible to break backwards
compatiblity by removing features that have been deprecated for at
least a single MINOR version.

PATCH versions contain only bug fixes. There will be no new features
or changes to the documented features (bugs are undocumented features
by definition :-). Whenever a MINOR release is made, a corresponding
branch is created in svn for the possible PATCH releases. Only bug
fixes will be committed to these branches.

The normal working model would then be evolutionary development in the
svn trunk with new MINOR releases being whenever a suitable set of new
features has been completed.


Jukka Zitting

Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftmanship, JCR consulting, and Java development
View raw message