I think we've talked a bit about a more flexible workflow to the
release, and doing some alternatives like creating a branch at the
release point and switching to it. I think it would be best for us to
lock down a 2.0 "final" release first before taking something like
that on, but if you wanted to try something in the sandbox it'd be
interesting to see :)
On 25/04/2008, at 1:07 AM, David Jencks wrote:
In my experience the release plugin currently works like this:
1. modifies working copy poms to release version
2. commits poms
3. does a repo-repo copy to the new tag
4. updates working copy poms to the new version
5. commits new-version poms.
Some projects (activemq) have a versioning scheme whereby branches,
say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such
as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The
current release plugin process thus results in 2 commits to all the
poms in the branch that modify the versions, then modify them back
to their original values.
This creates a fair amount of noise in the scm lists.
Would it be possible for the release plugin to do the following?
1. modify working copy poms to release version
2. do a working copy to repo copy for the new tag
3. adjust the working copy poms to the new version, or revert if the
new version is the same as the old version
4. commit the working copy poms if there is a new version.
Is this process svn specific? If so could it be provided as an
option?
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
