On 13 April 2010 12:04, Jeremy Hughes <[email protected]> wrote: > 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. >
Until parent and eba-maven-plugn @ 0.1-incubating are released, we'll need to temporarily make everything 0.2-incubating-SNAPSHOT. So here's what I'll do if there are no objections: Now 1. copy the current trunk to a branch in case we need it for updates to the release candidate 2. modify all artifact versions to 0.2-incubating-SNAPSHOT and have modules depend on those snapshots - like what we had before the release started but using 0.2-incubating-SNAPSHOT instead of 0.1-incubating-SNAPSHOT After 0.1-incubating has been released 1. released modules get the version of 0.2-incubating-SNAPSHOT 2. not yet released modules retain the version of 0.1-incubating-SNAPSHOT 3. all dependencies to released modules get a version of 0.1-incubating Subsequently, as soon as a module requires a change in an Aries top-level module it depends on, that dependency's version will need to move up to 0.2-incubating-SNAPSHOT If a checkin is made between now and releasing the 0.1-incubating RC, *and* that change depends on a change in another top-level module then the dependency relationship needs to stay at 0.2-incubating-SNAPSHOT even after 0.1-incubating has been released. I'm prepared to solve these when the 0.1-incubating release is published. wdyt? >> >> thanks >> david jencks >> >>> >>>> Joe >>>> >> >> >
