commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [COLLECTIONS] 3.3 RC1 for review
Date Sat, 23 May 2009 04:13:40 GMT
On Fri, May 22, 2009 at 3:56 AM, sebb <sebbaz@gmail.com> wrote:
> On 22/05/2009, Henri Yandell <flamefew@gmail.com> wrote:
>> On Thu, May 21, 2009 at 8:24 AM, sebb <sebbaz@gmail.com> wrote:
>>  > On 21/05/2009, Henri Yandell <flamefew@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.

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].

>>  >>  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.

>>  > 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?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message