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
