On 25/05/2009, Henri Yandell <flame...@gmail.com> wrote: > 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. >
Adding the revision number ensures uniqueness; URL+revision number is unique, but URL (whether tag or not) is not unique. It's very little work adding a single revision number for the tag. > >> 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; That's not always the case in commons. Some components don't use RC 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. Because tags *are* re-used in component releases - adding the revision is a very simple solution to ensure that even if so, the exact tag can be identified. > 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). I assume that it uses the tag, otherwise there is not much point in creating one. For the releases I have checked recently, the source archive agreed with the tag. > > >> >> >> 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. But who is to say that these are the same files as per the vote email? There have been commons votes where the same directory was used for a re-roll of a release that failed. > I'm still not getting it. > It's basically the same issue as the SVN tag. The file names alone are not enough to identify the artifacts. > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
