On 3/30/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Thu, 29 Mar 2007, Xavier Hanin <[EMAIL PROTECTED]> wrote: > http://incubator.apache.org/ivy/doc/dev.html > > I would like to get some feedback on this doc, to see if it makes > sense or not (from an Apache but also build and release point of > view). * be more specific about the version of JUnit (3.x or 4.x) in the building section - unless it doesn't matter, of course.
I haven't tested with junit 4.x, so I'll update the doc to ask for a 3.8.2version * creating a branch is optional, it depends on the project's
preferences, I guess. We haven't created a branch for 1.7.x, yet, for example. Maintaining two branches can be painful, so it may be a good idea to defer branching until you make changes to your trunk that you don't want to see in your next 2.0.x release.
The branch in my doc is only a release branch, not a branch for development. It allows to prepare the release in isolation, and commit things done only for the release (like updating template files). The aim is to avoid committing anything on that branch after the release is complete. If we tag only after the vote is successful, we could even remove the branch as soon as we tag the release. Does it make sense? * I'd add [email protected] to the "Announce" section. I'll do.
One thing I still don't know how to address is the case of a vote > rejecting the release. In this case, we'll need to update something > and submit again the release. So, is tagging before the vote a good > idea, or should we tag only when the vote is accepted (note that the > release is already build from a branch, so it's already safely > reproducible)? When I released AntUnit and the .NET Antlibs I created the tags in my filesystem (simple svn cp on directories instead of URLs) and committed them after the vote had passed. This is mostly a matter of taste since in svn a tag is not really frozen. I.e. if the vote fails you can simply either modify the tag or delete and recreate it.
So I think I'll say to tag only after the vote, since release preparation is already done on a branch, there is no risk for concurrent modifications.
Another thing with which I'm not familiar is signing. Do signing > files alter them? No. You'd create a detached signature which just like the checksum files is stand-alone.
Ok, so I'll add checksum generation in the build-release.xml script. But maybe signing could also be part of the script? If so, any example I could use? Oh, and one last question about distribution format: Ivy releases used to be distributed only in zip, should we also provide tar.gz? - Xavier Stefan
-- Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
