jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Jackrabbit 1.5 release structure
Date Sun, 12 Oct 2008 14:03:39 GMT
Hi,

With the 1.5 release coming up we need to come up with a consensus on
how the release should be structured. The per-component releases in
1.4.x have worked relatively well, allowing us to push out changes in
smaller increments, but have also caused confusion as to what exactly
is the latest Jackrabbit version. In Jackrabbit 1.5 I want to solve
these issues.

I strongly feel that a purely component-based release structure, i.e.
one in which each of our 16 components has completely independent
release cycle, is too fine-grained and makes building all of
Jackrabbit from anything but a composite trunk a futile effort. Using
a Jackrabbit source release should consist of downloading and building
just a single package.

On the other hand, we should only upgrade the version numbers of
individual components when they actually have changes. This will make
things clearer for downstream projects that have Maven dependencies to
just selected Jackrabbit components.

Putting these requirements together, here's what I would like to do
for the 1.5 release and any patch releases from the 1.5 branch.

* All 1.5.x releases will be snapshots of the entire 1.5 branch. This
keeps the source releases complete and in line with what a developer
normally checks out and builds.

* The version number of a component is only upgraded when the
component has been modified. This way downstream projects can easily
tell whether they should upgrade their dependencies. The upgraded
version number of a component will always match the version of the
entire release, so for example it will be possible (and probable) for
a jcr-commons version to jump for example from 1.5.2 to 1.5.6 with no
intermediate versions. The nice effect of this is that we won't need
to litter the Jira version list with dozens of component versions.

* Modifications to core components will trigger changes (if only the
dependency upgrade) also to dependent components. For example when
jackrabbit-core is modified, all the dependent components like jca and
webapp get upgraded.

I know this still doesn't answer the requirements of allowing mostly
independent components like commons, rmi, or ocm to freely evolve at
their pace. On a short term I suggest that we solve this mismatch with
more frequent 1.x minor releases so they would never stay too far
behind the progress in trunk. On a longer term we might want to branch
such components to real subprojects with their independent trunks,
Jira projects, etc.

BR,

Jukka Zitting

Mime
View raw message