*cough* Ignore that mail, my mailed marked it as new for some reason :)
Emmanuel Bourg a écrit :
Dumb question, why is there already a revision 1.1 published last
september in the Maven 2 repository ?
http://repo1.maven.org/maven2/org/apache/commons/commons-email/1.1/
http://mirrors.ibiblio.o
Dumb question, why is there already a revision 1.1 published last
september in the Maven 2 repository ?
http://repo1.maven.org/maven2/org/apache/commons/commons-email/1.1/
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/commons/commons-email/1.1/
Emmanuel Bourg
-
I've not looked at the release in any detail, just checked the sigs.
+1 assuming the main KEYS file gets updated before the RC is posted.
S///
On 27/09/2007, Ben Speakmon <[EMAIL PROTECTED]> wrote:
> committers/tools/releases. Another of Henri's little toys.
>
> So are you giving +1 for this RC
committers/tools/releases. Another of Henri's little toys.
So are you giving +1 for this RC or are there other concerns?
On 9/27/07, sebb <[EMAIL PROTECTED]> wrote:
>
> Ah, OK.
>
> BTW, where/what is this verify_sigs tool?
>
>
> On 27/09/2007, Ben Speakmon <[EMAIL PROTECTED]> wrote:
> > It wasn't
Ah, OK.
BTW, where/what is this verify_sigs tool?
On 27/09/2007, Ben Speakmon <[EMAIL PROTECTED]> wrote:
> It wasn't verify_sigs fault; I just uploaded the wrong file. When I ran it
> on the files I downloaded from RC2/, it complained correctly.
>
> On 9/26/07, sebb <[EMAIL PROTECTED]> wrote:
>
It wasn't verify_sigs fault; I just uploaded the wrong file. When I ran it
on the files I downloaded from RC2/, it complained correctly.
On 9/26/07, sebb <[EMAIL PROTECTED]> wrote:
>
> All the MD5 and ASC files check out OK now.
>
> Why did verify_sigs not complain before?
> If it's faulty, it nee
All the MD5 and ASC files check out OK now.
Why did verify_sigs not complain before?
If it's faulty, it needs to be fixed - or abandoned as a check.
S.
On 26/09/2007, Ben Speakmon <[EMAIL PROTECTED]> wrote:
> Turns out those assemblies had an outdated POM in them. I've rebuilt them
> with the pom
Turns out those assemblies had an outdated POM in them. I've rebuilt them
with the pom tagged as RC2. Since there were no other changes, I replaced
the broken ones in my RC2/ directory with the new ones.
Can you please recheck?
On 9/25/07, sebb <[EMAIL PROTECTED]> wrote:
>
> OK, I've now got your
OK, I've now got your key.
However, the following sigs don't work for me:
commons-email-1.1-RC2-bin.zip.asc
commons-email-1.1-RC2-bin.tar.gz.asc
commons-email-1.1-RC2.jar.asc
Same files that have the MD5 problems.
S///
On 25/09/2007, Ben Speakmon <[EMAIL PROTECTED]> wrote:
>
> My key is in tru
Ben Speakmon wrote:
New source and javadoc jars have been uploaded, tag has been reapplied, and
signatures rechecked. Votes again welcome :)
The source jar now contains LICENSE/NOTICE twice, but that's no problem
IMO. You have my +1.
Oliver
On 9/24/07, Ben Speakmon <[EMAIL PROTECTED]> wro
My key is in trunks-proper (
http://svn.apache.org/repos/asf/commons/trunks-proper/) but it hasn't been
copied to the main KEYS file yet.
I'll double-check the MD5s. verify_sigs swore they were correct :)
On 9/25/07, sebb <[EMAIL PROTECTED]> wrote:
>
> Also, I can't find the signing key - it does
Also, I can't find the signing key - it does not seem to be in
http://www.apache.org/dist/commons/KEYS
but perhaps it is elsewhere?
On 25/09/2007, sebb <[EMAIL PROTECTED]> wrote:
>
> Some of the MD5s don't work for me:
>
> BAD MD5 commons-email-1.1-RC2.jar
> Expect: fb02f6aff49332705084b662a5d8d
Some of the MD5s don't work for me:
BAD MD5 commons-email-1.1-RC2.jar
Expect: fb02f6aff49332705084b662a5d8d945
Found: a2d70201e44041f9d9b3d865c615e35f
BAD MD5 commons-email-1.1-RC2-bin.tar.gz
Expect: f7d933426b68e184047405b52e9bfa0c
Found: 770a8da798eb94137e24e03da2904a66
BAD MD5 commons-email
Ben Speakmon wrote:
> New source and javadoc jars have been uploaded, tag has been reapplied,
> and signatures rechecked. Votes again welcome :)
+1
Looks good, src-package compiled and ran all tests for my complete compiler
zoo.
- Jörg
-
New source and javadoc jars have been uploaded, tag has been reapplied, and
signatures rechecked. Votes again welcome :)
On 9/24/07, Ben Speakmon <[EMAIL PROTECTED]> wrote:
>
> Just wanted to make sure.
>
> I will update the RC sources.jar and javadoc.jar with versions that put
> the LICENSE/NOTIC
Just wanted to make sure.
I will update the RC sources.jar and javadoc.jar with versions that put the
LICENSE/NOTICE in META-INF. I'll check in the POM and retag as RC2, leaving
the current RC2 artifacts on people.a.o in place as there are no code
changes. Is everybody okay with that plan?
On 9/2
Ben Speakmon wrote:
That settles it for me. Do we need to put LICENSE/NOTICE in META-INF in
source and javadoc or is the root directory acceptable?
AFAIK these files have always been stored in META-INF.
On 9/24/07, Oliver Heger <[EMAIL PROTECTED]> wrote:
Ben Speakmon wrote:
I wasn't sure w
That settles it for me. Do we need to put LICENSE/NOTICE in META-INF in
source and javadoc or is the root directory acceptable?
On 9/24/07, Oliver Heger <[EMAIL PROTECTED]> wrote:
>
> Ben Speakmon wrote:
> > I wasn't sure what to make of it either; the release docs don't mention
> it
> > specifica
Ben Speakmon wrote:
I wasn't sure what to make of it either; the release docs don't mention it
specifically. The source and javadoc jars, BTW, are intended to be deployed
next to the final build in the maven repo. It won't be hard to make sure
they get in there. Is there a consensus that it's req
I wasn't sure what to make of it either; the release docs don't mention it
specifically. The source and javadoc jars, BTW, are intended to be deployed
next to the final build in the maven repo. It won't be hard to make sure
they get in there. Is there a consensus that it's required for this release
Everything looks good, except for one thing, which I think needs to be
fixed: the jar with the javadocs does not contain NOTICE.txt and
LICENSE.txt. (The jar with the sources contains these files, but they
are stored in the top level rather than in META-INF; don't know whether
this is problemat
I believe we said that we're not keen on changing groupIds for
components that have had releases ( WRT r575823 [1] ).
-Rahul
[1] http://svn.apache.org/viewvc?view=rev&revision=575823
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
F
> I agree with Oliver though that the backward compat isssue requires a
> major version bump and ideally deprecation before that. Any way it
> can be worked around?
Sure, I can just rename the new field and deprecate the new one.
A few more observations.
>
> 1) I notice that the src distro incl
On 9/19/07, Ben Speakmon <[EMAIL PROTECTED]> wrote:
> *groan* *shuffle*
>
> a zombie commons project rises to stalk the earth again, hungry for votes...
>
> Seriously, it'll be two years next Saturday since 1.0 was released, and
> after a fair bit of work on closing existing bugs and adding simple
The artifacts all look good to me, so I would be +1.
However this breaking change concerns me. Our versioning guidelines so
far have been that a binary incompatible release must have a new major
version number. In this concrete case, as I understand it, impact seems
to be pretty low. Neverthel
25 matches
Mail list logo
