On 23/05/2009, Henri Yandell <flame...@gmail.com> wrote: > On Fri, May 22, 2009 at 3:56 AM, sebb <seb...@gmail.com> wrote: > > On 22/05/2009, Henri Yandell <flame...@gmail.com> wrote: > >> On Thu, May 21, 2009 at 8:24 AM, sebb <seb...@gmail.com> wrote: > >> > On 21/05/2009, Henri Yandell <flame...@gmail.com> wrote: > >> >> I don't expect this to pass the first vote - they never do :) > >> >> > >> >> --- > >> >> > >> >> Tag: > >> >> > >> >> > https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_3_RC1 > >> > > >> > Which revision is this? I'm assuming r777000 (nice number!) > >> > >> > >> Not a clue :) > > > > Since tags are not guaranteed immutable, it's necessary to qualify the > > URL with the revision. This is present in the original commit message > > and svn info / Last Changed Rev: > > > 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. > 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. > >> >> 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. > >> > It would be nice if the javadoc and source jar manifests included the > >> > Specification and Implementation headers. See commons-compress pom.xml > >> > for how to add these. > >> > >> > >> Done. Presumably there's a Maven2 bug that stops us fixing this in the > parent? > >> > > > > No idea. I think it's only recently that the source and javadoc > > plugins were updated to support the manifests, so it might work if it > > were tried now. > > > Why wouldn't it have worked before? Or was compress just a safety attempt? My reply was badly phrased. I just meant that the current commons parent was created a while ago. The javadoc plugin needs to be a more recent version in order to apply the manifest fixes. So it presumably would not have worked when parent 11 was created. > > 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
