+1

regards
 marcel

Jukka Zitting wrote:
Hi,

We have a relatively short term need to do patch releases and I don't
want to introduce too big changes in the 1.4 (and 1.3) branch, so
here's a proposal for an intermediate solution for patch releases
until we reach a better consensus on what to do in trunk. In fact I
think we should use something like this even after (or if) we split
Jackrabbit to subprojects.

----

JACKRABBIT PATCH RELEASES

Granularity

A patch release will only contain a single Jackrabbit component. Bug
fixes to multiple components will go out in multiple patch releases.

Version control

Bug fixes targeted to a patch release should first be committed in
Jackrabbit trunk, and then merged (preferably using "svn merge" where
possible) to the appropriate branch. Fixes to issues that are no
longer present in trunk (for example because of some refactoring) can
be committed directly to a branch.

Once all planned bug fixes have been merged or committed to the branch
and any administrative changes (version number update, etc.) have been
made, the component to be released will be tagged from the branch
using a command like:

    svn copy -m 'x.y: Tagged component-x.y.z' \
        https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \
        https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z

The contents of the tag should never be changed.

Issue tracker

Patch releases will be tracked by assigning each of them a separate
component-version (e.g. jackrabbit-core-1.4.2) tag in the issue
tracker. All bug fixes to be included in a patch release should be
tagged with the respective version tag.

Note that this will likely cause problems later on by inflating the
list of release versions, but hopefully by that time we have split the
release process to more manageable subprojects.

Parent POM

The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not
be changed or included in a patch release. A component POM needs to
explicitly override parent settings if it needs such changes in a
patch release.

Note that POM changes (apart from version updates) should normally not
be needed in patch releases.

Patch dependencies

Bug fixes in patch releases should normally not depend on changes in
other components or external dependencies. In case they do (and there
is a solid reason for doing that), such updated dependencies should be
explicitly declared in the component POM and clearly described in the
patch release notes.

Announcements

Normal patch releases will be announced on the Jackrabbit dev@,
users@, and announce@ mailing lists, but not on [EMAIL PROTECTED]
Patch releases containing fixes to critical security issues will also
be announced on [EMAIL PROTECTED]

----

WDYT?

BR,

Jukka Zitting


Reply via email to