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
cycle.
* Components maybe released at the same time if there exist
dependencies.
* Whether a component is released at a minor or micro version
number depends only on the changes contained in the
component.
* 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. 1.4.2.1433
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.
WDYT?
Regards
Felix
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.
WDYT?
BR,
Jukka Zitting
