jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Component releases, proposed solution
Date Tue, 22 Jul 2008 12:55:24 GMT
Hi,

I'm not sure about all the implications such a change has, but I like the idea 
to have an overall jackrabbit release version.

It would certainly make downloading and using the latest jackrabbit version a 
lot easier.

regards
  marcel

Jukka Zitting wrote:
> Hi,
> 
> 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
> repository
> * 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
> issues
> * 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.
> 
> WDYT?
> 
> BR,
> 
> Jukka Zitting
> 


Mime
View raw message