Hi, On 1/15/06, Roy T. Fielding <[EMAIL PROTECTED]> 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. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftmanship, JCR consulting, and Java development
