Hi Jukka, ++1
I think this is a very valuable strategy moving forward for our patch releases. And it will probably also show, that we might handle the trunk in a similar manner as we would start handling the branch(es). Thanks for this proposal. Regards Felix Am Montag, den 21.01.2008, 12:11 +0200 schrieb Jukka Zitting: > 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
