On 12 April 2010 21:19, Joe Bohn <[email protected]> wrote: > On 4/12/10 1:00 PM, Jeremy Hughes wrote: >> >> On 12 April 2010 14:19, Joe Bohn<[email protected]> wrote: >>> >>> All, >>> >>> First off - Thanks to Jeremy for pulling together this release and doing >>> the >>> really hard work of sorting out the details the first release. I know >>> this >>> is a difficult and often frustrating effort. >>> >>> This thread can server to discuss anything related to the vote. >>> >>> A few comments/things to consider: >>> 1) There were some manual changes necessary to update the version in >>> properties and a few other places. We might be able to remove some of >>> these >>> but I'm sure not all of them. However, it does create a problem because >>> we >>> now have to change them to the "real" version number before running the >>> maven-release-plugin but then that puts trunk in a dangerous state in >>> trunk. >>> Perhaps we should consider creating a branch before a release process >>> from >>> the branch. That way work on trunk to continue and the branch could >>> remain >>> with the hard coded versions (and basically frozen) until we ultimately >>> release and need to update the hard-coded versions to the next snapshot. >>> I'm not sure if that really solves all of the issues but it might be a >>> little better. >>> >>> 2) Because we didn't release every project we now have a mixture of >>> 0.2-incubating-SNAPSHOT and 0.1-incubating-SNAPSHOT versions in trunk. I >>> wonder if we should bump all of trunk up to the next snapshot version to >>> keep things consistent and easier to manage. If we choose to have >>> multiple >>> versions represented in the various projects in trunk then we might need >>> to >>> do a little more pom cleanup to ensure that we can support this >> >> Looking at the next stage of the release process, it is either to >> rollback or to promote. It doesn't look like there is anything that >> needs doing in SVN if we promote the staged artifacts which makes me >> think they should right now be at 0.2-incubating-SNAPSHOT. However, if >> we need to go down the rollback route for some reason then the >> instructions [1] for rollback suggest what's in SVN should stay as it >> is. Anyone wish to comment? >> >> [1] >> http://maven.apache.org/plugins/maven-release-plugin/examples/rollback-release.html > > > What was being proposed was just 2 things and I don't think either of them > will impact a potential rollback. > 1) Changing the entries that still have 0.1-incubating-SNAPSHOT to > 0.2-incubating-SNAPSHOT. This should only be for projects that are not > currently up for vote anyway and so it should not be affected by a rollback. > Of course, if we did rollback we would once again have an inconsistency > between 0.1-incubating-SNAPSHOT components and 0.2-incubating-SNAPSHOT - but > that should be just a temporary issue while a new RC is being created which > is usually much quicker on the second time around. > 2) Changing the entries that currently have 0.1-incubating to > 0.2-incubating-SNAPSHOT. I think all of these entries were manually edited > to reflect to the proposed release. Therefore, the maven-release-plugin > rollback would also not affect these entries.
In fact mvn versions:update-parent changed the <parent><version> element. The procedure was to run this before running mvn versions:use-releases. That said, I think these commands are just a convenience over doing it manually. > > Of course, if we did rollback we would have inconsistent versions again - > particularly for those versions that were manually updated in #2 - but that > would also be the case even if we don't update them now - > 0.1-incubating-SNAPSHOT (after a rollback) doesn't match > 0.2-incubating-SNAPSHOT (if we do update now) or 0.1-incubating (if we don't > update now). > I'm +1 for moving up to 0.2-incubating-SNAPSHOT then figuring out what we need to do later if we need to cut another RC. > Joe >
