jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Component releases, proposed solution
Date Wed, 23 Jul 2008 07:35:00 GMT
Hi Jukka,

Thanks for bringing this up in this concise form. I basically agree with 
what you propose. Yet a big question turns around in my head: What 
exactly _is_ Jackrabbit ?

Well, Jackrabbit is a JCR 1.0 implementation you might say. Quite true. 
But this falls short, because this only relates to jackrabbit-core 
(along with the API and commons libraries required).

So, you might say Jackrabbit is a project providing a JCR 1.0 
implementation and other stuff related to JCR in general and Jackrabbit 
in particular. Some such stuff coming to mind is SPI, RMI, Object 
Content Mapping, Web Application, two flavors of WebDAV and more ...

<sidenote>SPI and RMI actually are in some sense JCR 1.0 implementations 
on their own right</sidenote>

So, what _is_ Jackrabbit ? Or maybe: What is _the_ Jackrabbit Release ? 
I can't tell. And maybe it is not important right now.

Right now, it is important to say:

   * Each component has its own versioning scheme and release
   * Components maybe released at the same time if there exist
   * Whether a component is released at a minor or micro version
     number depends only on the changes contained in the
   * Jackrabbit Release(s) comprising multiple components have
     their own version number themselves. Whether minor or micro
     versions are released has to be decided on a release by
     release level.
   * Jackrabbit Release(s) do _not_ trigger component releases.
     Rather they just "package" the latest component releases.

The "Jackrabbit release" does not need to contain the latest nitty 
gritty feature. Rather it must be easily usable out of the box to test 
drive it or to just have something proven and tested (over time not just 
with automated tests).

As corrolary to these notes, I would add (yes these will be 
controversial, I know):

   * Branches are used for development and not for releases.
   * Releases are (almost) only cut from trunk
   * In case of an important bugfix to be applied to an old
     release, a branch will be created from the respective
     release tag and a release number with qualifier (fourth
     place in the version number, the major/minor/micro
     version numbers are the same) is created. E.g.
     where 1433 might be the JIRA issue containing the comments
     leading to this release and 1.4.2 is the release (tag)
     from which the bug fix release was branched.

Why this ?

Trunk should always be as stable as possible. Releases are built from 
tags based on trunk. This further simplifies the release procedure as 
there is no more branching and nore more bug fix back porting.

Major new developments -- the implementation of the foreseen JCR 2.0 ACL 
functionality comes to mind -- should be done on development branches 
and merged back into trunk as the developer(s) see fit aka ready for 
release. Regular development still takes place on trunk, of course.

This simplifies the world for our users: We just tell them take the 
latest Jackrabbit release or take trunk. Both will work. It complicates 
matters a bit for those developers implementing major features having to 
work on a branch instead of trunk. But these are a minority compared to 
all the other developers and -- most importantly -- our users.



Jukka Zitting schrieb:
> 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.
> BR,
> Jukka Zitting

View raw message