Siegfried Goeschl wrote:
Hi Scott,
I'm sorry for the long delay but I had to meet a project deadline today and your question needs a thoughtful answer ...
Some Prerequisites
=========================================================================
+) we need a quick and painless way to release a fulcrum component
+) I would like to release a lot of them and I can't spend half a day on a
single release
+) I personally don't have the same quality requirements for releasing a
fulcrum component as I would have on commons or maven-plugins
I agree on the above three points.
+) in commons land the discussion is ongoing (or
http://wiki.apache.org/commons/CreatingReleases)
I'm going to rely on you to keep an eye on developments in the
discussion - so much to read, so little time.
There a many ways to skin the cat
=========================================================================
1) follow the guidelines found here (http://maven.apache.org/developers/release/releasing.html)
2) make the release from SVN directly also using the release plugin
Ad 1) that stuff is complicated and is probably fragile
Ad 2) this is much quicker but if multiple developers are working on the code it can break. So you should declare a "ceasefire" before running the release process but we have not a lot of SVN activity anyway so this is not an issue.
We are certainly not tripping over one and other to release components
(or anything else for that matter).
Using 2) has two flavors
2.1) make a complete release using "mvn release:prepare" and "mvn
release:perform" - in this case the review needs to be done on an RC tag since the release tag
is created only during the release process. This approach I used for releasing the
fulcrum-parent.pom
So to be clear, does this mean that after the vote a new release is cut
using the final tag which is then deployed? If it is a repeatable
process with only the version changing in the pom then this is probably
acceptable.
2.2) run "mvn release:prepare", create the artifacts for reviewing and do "mvn -D
connectionUrl release:preform". If the review fails you need to remove the SVN tag which is
kind of dirty because that SVN directory should be considered read-only. But again not a big issue
Conclusio
=========================================================================
+) setting up the release process is difficult since it has many implications
and subtle problems
+) I personally lean towards 2.1) or 2.2)
I don't think we can afford to be anything other than pragmatic. We
need to follow the rules in terms of reviewing code and releases, but
the process needs to be as quick and painless as possible, so you have
my full support in moving our processes in this direction.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
