BTW I think you can alleviate the current build problems by checking out the tags and building them yourself.... or, if you are voting, you will already have downloaded the source bundles and built them to make sure they are buildable -- pretty much the closest thing to a requirement for voting on an apache release.
thanks david jencks On Apr 12, 2010, at 3:32 PM, David Jencks 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. > > thanks > david jencks > >> >>> Joe >>> >
