excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Excalibur Release Plan
Date Tue, 12 Apr 2005 13:27:58 GMT
On 11-04-2005 16:56, "J Aaron Farr" <jaaronfarr@gmail.com> wrote:
>>  Do I need to tag SVN for this?
> Yes.
>> I am assuming I do. Unless someone tells me
>> how to do this easily for all the modules, I think I am going to write
>> something in Jelly for Maven to allow use of the multiproject plugin, derive
>> a tag from currentVersion and apply the tag (doesn't look like Maven's scm,
>> repository, release plugins do what we need).
> You could tag the whole 'trunk' but tagging individual component
> directories would be much better.

Uh, please do tag the entire trunk for a specific version of a specific
component, ie something like

$ svn cp https://svn.apache.org/repos/asf/excalibur/trunk \

Copies in SVN are real cheap, and doing things this way makes it a lot
easier to track version (mis)matches years down the road, etc etc.

Also note the stuff in buildsystem/ already does this kind of tagging, might
want to look at that.

>>  BTW, project-common.xml is
>> evil for this purpose....need to tag the parent dir even though only a
>> nested dir/project is being released.
> You want to include the 'buildsystem' directory in each tag?   One
> layout I suppose would be:
>   /tags
>      /${artifact}-${version}
>           /buildsystem
>           /[actual source directories here]
> Is this what you were envisioning?

Why is it evil to tag the entire tree? It doesn't cost us any disk space,
you can be certain that everything in /tags is a copy of something that was
a /trunk at one point, you get an easy way to figure out what state the tree
was in when a release was made, etc etc.

SVN is simply way better for this kind of stuff than CVS :-D

In general
Thanks for getting to work on this! Please make sure to follow through on or
http://wiki.apache.org/excalibur/ReleaseManagement and
http://wiki.apache.org/avalon/AvalonReleaseManagerHowto (hmm, might make
sense to copy the information in there that's still useful over to our own

It's not *that* big of a problem if a release isn't perfect as long as its
real easy to retract it and publish an updated version. "Real easy" among
other things means being very thorough in documenting all the steps and
automating as much as possible.

Finally, let's please make sure to not mess up http://www.apache.org/dist/.
It took quite a bit of effort to get that cleaned up (Henk Pennig maintains
stats on that@ http://people.apache.org/~henkp/) :-D



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

View raw message