On 12 April 2010 23:32, David Jencks <[email protected]> wrote: > > On Apr 12, 2010, at 2:08 PM, Jeremy Hughes wrote: > >> 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. > > I agree. > >> >>> >>> 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. > > I'm not quite sure what changes are being proposed here. I would definitely > leave all references to the parent and eba-maven-plugin at 0.1-incubating > until there is some need to change them. Depending on snapshot versions > should be avoided when possible. I would look carefully at upgrading other > snapshots to make sure there is a dependency on code changes since the > release. Slightly annoying, but I think we already decided that we weren't > going to keep the subprojects in lockstep..... this is where it starts to > show.
So subsequent to a release, each top level module should have its own <version> moved up one, e.g. from 0.1-incubating to 0.2-incubating-SNAPSHOT and since a release has just happened it shouldn't have any dependencies on snapshots and it should remain that way until a need arises. I think we're saying the same thing, just wanted to make sure. > > thanks > david jencks > >> >>> Joe >>> > >
