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
>> 

Reply via email to