SVN === On 11-04-2005 16:56, "J Aaron Farr" <[EMAIL PROTECTED]> 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 \ https://svn.apache.org/repos/asf/excalibur/tags/excalibur-blah.x.y 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 update 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 wiki). 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 Cheers! Leo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
