OK. I'll make the change so at least trunk is buildable. Thanks
On 13 April 2010 15:53, Joe Bohn <[email protected]> wrote: > > I'm OK with a temporary change to 0.2-incubating-SNAPSHOT but the issue > isn't as simple as just moving back to 0.1-incubating after the release is > published (see my other post). Therefore, your proposal for what to do > after 0.1-incubating has been released will just surface the same issue that > I mentioned in that other post. We will need to make some changes in how > the version ranges specified for the maven-bundle-plugin (currently a > default in the default-parent pom). > > Joe > > On 4/13/10 9:05 AM, Jeremy Hughes wrote: >> >> 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 >>>>>> >>>> >>>> >>> >> > > > -- > Joe >
