Leo,
No matter how cheap, copying the entire tree has got to be more than just tagging the parts we need. Since we have (tagged) POMs that will tell us the dependency versions, we can figure out the state of the other modules when a particular module is released and tagged. However, that's all theory. Given that our repo is currently based on one trunk for all of Excalibur, I am fine with copying/tagging the entire trunk for the release of each component/module.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.
Will do....thanks for the pointer.
Really shouldn't care about the rest of the tree as long as we are releasing/tagging each module on it's own. The "other" Avalon components in the tree should appear to the component in question just the same as any old dependency from some other project (which of course will not be tagged).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.
But, that's for the sake of arguments; as above, going with the entire trunk copy for now.
I do like the fact that we can move files/dirs ariund without loosing history.SVN is simply way better for this kind of stuff than CVS :-D
Will do. Aaron and infrastructure are still trying to get me access so I can commit (my testcase is the typo you mentioned, so don't fix it :-)). I will update, reuse, automate, document :-)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
Shash
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
