jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Component releases, proposed solution
Date Tue, 22 Jul 2008 10:51:26 GMT

There's been a lot of discussion about release strategy and
componentization lately, and I've been trying to figure out how to fit
all the different requirements into a single solution for Jackrabbit
1.5+. Here's what I have in mind...

First, the main requirements for componentization:

* The codebase should be reasonably modular based on exposed
functionality and required dependencies
* Component release cycles should be independent except as constrained
by functional dependencies

But also:

* It should be easy to download (or checkout) and build all of Jackrabbit
* A Jackrabbit installation should have a clear version number that
identifies the exact contents of the installation

To cover all of these requirements I propose:

* We keep a single release cycle for all of Jackrabbit (including a
single trunk,branches,tags structure, single Jira project, etc.)
* Each component within Jackrabbit trunk (and branches) has an
independent version number that is only increased based on actual
changes in the component
* Thus a "Jackrabbit release" contains a collection of different
component versions that are known to work well together
* When making a release, only those components that have been modified
(and thus have a new version number) are deployed to the Maven
* Release notes will contain a list of included component versions and
the changes to each component

The effects of this policy would be:

* Downstream projects like Sling that use direct Maven dependencies to
Jackrabbit components have an easier time tracking actual changes in
the components
* The concepts "Jackrabbit release" and "Jackrabbit version" are still
simple to grasp and use for example when reporting or reproducing
* There's still a single trunk where development of all components occurs

Applied to the Jackrabbit 1.4.x release cycle, this would have given
us the following releases:

* Jackrabbit 1.4.1, including core 1.4.1
* Jackrabbit 1.4.2, including core 1.4.2
* Jackrabbit 1.4.3, including jcr-commons 1.4.1 and jcr-rmi 1.4.1
* Jackrabbit 1.4.4, including core 1.4.3
* Jackrabbit 1.4.5, including core 1.4.4
* Jackrabbit 1.4.6, including core 1.4.5

Also, each release would have contained updated versions of aggregate
components like jackrabbit-webapp and jackrabbit-jca, whose version
numbers would thus follow the top level version number.



Jukka Zitting

View raw message