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
