aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: [DISCUSS] Apache Aries (Incubating) v0.1 release candidate
Date Tue, 13 Apr 2010 14:55:03 GMT
OK. I'll make the change so at least trunk is buildable.


On 13 April 2010 15:53, Joe Bohn <> 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<>  wrote:
>>> On 12 April 2010 23:32, David Jencks<>  wrote:
>>>> On Apr 12, 2010, at 2:08 PM, Jeremy Hughes wrote:
>>>>> On 12 April 2010 21:19, Joe Bohn<>  wrote:
>>>>>> On 4/12/10 1:00 PM, Jeremy Hughes wrote:
>>>>>>> On 12 April 2010 14:19, Joe Bohn<>  
>>>>>>>> All,
>>>>>>>> First off - Thanks to Jeremy for pulling together this release
>>>>>>>> doing
>>>>>>>> the
>>>>>>>> really hard work of sorting out the details the first release.
>>>>>>>> know
>>>>>>>> this
>>>>>>>> is a difficult and often frustrating effort.
>>>>>>>> This thread can server to discuss anything related to the
>>>>>>>> A few comments/things to consider:
>>>>>>>> 1)  There were some manual changes necessary to update the
>>>>>>>> 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
>>>>>>>> because
>>>>>>>> we
>>>>>>>> now have to change them to the "real" version number before
>>>>>>>> the
>>>>>>>> maven-release-plugin but then that puts trunk in a dangerous
>>>>>>>> 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
>>>>>>>> ultimately
>>>>>>>> release and need to update the hard-coded versions to the
>>>>>>>> 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
>>>>>>>> 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
>>>>>>> Looking at the next stage of the release process, it is either
>>>>>>> rollback or to promote. It doesn't look like there is anything
>>>>>>> needs doing in SVN if we promote the staged artifacts which makes
>>>>>>> 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]
>>>>>> What was being proposed was just 2 things and I don't think either
>>>>>> them
>>>>>> will impact a potential rollback.
>>>>>> 1)  Changing the entries that still have 0.1-incubating-SNAPSHOT
>>>>>> 0.2-incubating-SNAPSHOT.  This should only be for projects that
>>>>>> not
>>>>>> currently up for vote anyway and so it should not be affected by
>>>>>> 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
>>>>>> 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

View raw message