On Sat, May 23, 2009 at 3:33 AM, sebb <seb...@gmail.com> wrote: > On 23/05/2009, Henri Yandell <flame...@gmail.com> wrote:
>> Maven release plugin is the one doing the copy to the branch. So I >> don't see the commit message (well.. it's probably somewhere in the >> huge load of text that passes through). It also changes things before >> the copy, and afterwards, so svn info won't give correct info. > > The revision is in the message sent to commits @ c.a.o which all > developers should follow. > > AFAIK, Maven does not change the tag after it has created it, so the > SVN Info will be accurate - though you need to look at Last Changed > Revision, which will be the same as when the tag was created. And at the end of the day you still have to trust me as the RM that what I built came from that tag? (or in fact that tag happened somewhere in the middle of the release plugin). It's a lot of make-work as far as I can tell. >> If I wasn't using the maven release plugin then I'd be building from >> an export of svn. Then svn info could be used. >> >> [says I with some level of irkdoom. When you try to control someone's >> development process, you remove their ability to be agile in >> situations like this]. >> > > Huh? > > All I'm saying is that the URL needs to be qualified with the revision > otherwise it's not guaranteed unique. One small piece of information > to be added to the VOTE message. It's unnecessary. We have social conventions in place - ie) don't modify tags; we have commit mails to show whether they have been; we have a do-magic tool that doesn't explain what it built the release from and you want the revision # for a URL that is only added to the release mail as an afterthought. :) I agree fully that a URL isn't guaranteed unique - but I don't see the point in needing it. Anyway - you can see the commit mails too, I've no clue which one is the one used to make the source (yup, I feel queasy using the mvn release-plugin as I don't like releasing with a magic red button, but am not taking the time to pull it apart and learn what it does). >> >> >> Binaries: >> >> >> >> >> >> >> http://people.apache.org/builds/commons/collections/3.3/RC1/staged/commons-collections/commons-collections/3.3/ >> >> > >> >> > It would be useful to record the Md5 hashes, because the same file >> >> > names will be used for RC2 etc: >> >> >> >> >> >> I don't understand. >> >> >> > >> > The file names don't include the RCn suffix, so a second RC would use >> > the same name. >> > The MD5s are needed to ensure that we are voting on the same artifacts. >> >> >> But you're not. New artifacts are generated. > > Yes, but the same artifact names are re-used. Sometimes the same > directory name is re-used as well. > > So to ensure that we are all voting on the same versions of the > artifacts, the hashes are needed. They are in md5 files next to the files themselves. I'm still not getting it. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
