[release plugin] Suggestions for Release Plugin

[Sean Schofield <se...@gmail.com>]

I have a few suggestions for ways to improve the release plugin.  I
can post a JIRA issue of course but I wanted to get some general
thoughts before adding an issue.

We are using the release plugin on the MyFaces project.  Its working
quite well except for a few issues.  I will present a simplified
example of our dilema to illustrate our difficulties.

Two projects: commons and core.  Both are on the trunk and have
version 1.0.0-SNAPSHOT.  Core depends on commons.  We release commons
as 1.0.0 and increment the version on the trunk to 1.0.1-SNAPSHOT.

Now its time to get ready to release core.  Lets say we want to branch
now and release in a few weeks after testing.  I'd like to create the
branch for the upcoming release and the release:prepare stuff is close
to what we want but not quite.  If you use release:prepare with a
tagBase pointing to your branches dir in SVN, Maven complains about
release depending on a snapshot (commons is now 1.0.1-SNAPSHOT in the
trunk.)

The problem is that we're not releasing yet (just preparing.)  Ideally
prepare would only create the branch, strip the SNAPSHOT from the
version on the branch (for core) and incremented the SNAPSHOT version
on the trunk (for core.)  I think it makes more sense for the
release:perform to concern itself with the existence of SNAPSHOT
dependencies (when you're actually ready to release.)  This way we
could manually change the commons dependency on the branch to 1.0.0
yet take advantage of Maven's ability to increment the versions on the
trunk and strip the snapshot from the branch.

One idea I had was a branchBase argument that would indicate the user
is interested in preparing for an eventual (but not immediate)
release.  It would also be helpful if the release.properties were
checked in (without any sensitive passwords in the file) so someone
else could perform the release if the person who prepared it is
unavailable.

Thoughts?

Sean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [release plugin] Suggestions for Release Plugin

[Brett Porter <br...@apache.org>]

Apologies for the late reply.

I think the key here is the perception of the dependency version. You
should actually declare what you need, not what you want :)

Basically, you shouldn't be upgrading to 1.0.1-SNAPSHOT on the core
release until such point as you actually want to use it from core. And
if you are using it from core, you can't release against it as it is a
SNAPSHOT.

Ideally, you could use versions to alleviate this: [1.0,) says you only
need 1.0, but if 1.0.1-SNAPSHOT is available you'll use it.

- Brett

Sean Schofield wrote:
> I have a few suggestions for ways to improve the release plugin.  I
> can post a JIRA issue of course but I wanted to get some general
> thoughts before adding an issue.
> 
> We are using the release plugin on the MyFaces project.  Its working
> quite well except for a few issues.  I will present a simplified
> example of our dilema to illustrate our difficulties.
> 
> Two projects: commons and core.  Both are on the trunk and have
> version 1.0.0-SNAPSHOT.  Core depends on commons.  We release commons
> as 1.0.0 and increment the version on the trunk to 1.0.1-SNAPSHOT.
> 
> Now its time to get ready to release core.  Lets say we want to branch
> now and release in a few weeks after testing.  I'd like to create the
> branch for the upcoming release and the release:prepare stuff is close
> to what we want but not quite.  If you use release:prepare with a
> tagBase pointing to your branches dir in SVN, Maven complains about
> release depending on a snapshot (commons is now 1.0.1-SNAPSHOT in the
> trunk.)
> 
> The problem is that we're not releasing yet (just preparing.)  Ideally
> prepare would only create the branch, strip the SNAPSHOT from the
> version on the branch (for core) and incremented the SNAPSHOT version
> on the trunk (for core.)  I think it makes more sense for the
> release:perform to concern itself with the existence of SNAPSHOT
> dependencies (when you're actually ready to release.)  This way we
> could manually change the commons dependency on the branch to 1.0.0
> yet take advantage of Maven's ability to increment the versions on the
> trunk and strip the snapshot from the branch.
> 
> One idea I had was a branchBase argument that would indicate the user
> is interested in preparing for an eventual (but not immediate)
> release.  It would also be helpful if the release.properties were
> checked in (without any sensitive passwords in the file) so someone
> else could perform the release if the person who prepared it is
> unavailable.
> 
> Thoughts?
> 
> Sean
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org