You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ben Speakmon <bs...@apache.org> on 2007/09/20 06:43:48 UTC

[VOTE] Release Email 1.1

*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 new
features, I'd like to put it to a vote.

Artifacts:
http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/

Staged site:
http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/site/

Release notes:
http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/RELEASE-NOTES.txt

clirr:
http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/clirr.txt

rat:
http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/rat.txt

There is one breaking change to point out: the protected field
HtmlEmail.inlineImages was changed from a List to a Map. This was done
because the original implementation didn't work correctly. There's no reason
why this field can't be private, since the class isn't designed for
extension. I figured that changing the type and not the visibility would
give that one guy who did subclass the chance to find out and fix it. Aside
from this, all other changes are fixes or additions.

[] +1
[] +/-0
[] -1

My +1 is nonbinding for this vote, so we need three okeydokeys from vested
PMC members.

Vote will close Saturday at 22:00 PDT.

Thanks,
--Ben

Re: [VOTE] Release Email 1.1

Posted by Oliver Heger <ol...@oliver-heger.de>.
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. Nevertheless, wouldn't it be possible to deprecate the 
old list field and add the map field with a new name, thus staying 
binary compatible?

Oliver

Ben Speakmon 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 new
> features, I'd like to put it to a vote.
> 
> Artifacts:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/
> 
> Staged site:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/site/
> 
> Release notes:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/RELEASE-NOTES.txt
> 
> clirr:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/clirr.txt
> 
> rat:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/rat.txt
> 
> There is one breaking change to point out: the protected field
> HtmlEmail.inlineImages was changed from a List to a Map. This was done
> because the original implementation didn't work correctly. There's no reason
> why this field can't be private, since the class isn't designed for
> extension. I figured that changing the type and not the visibility would
> give that one guy who did subclass the chance to find out and fix it. Aside
> from this, all other changes are fixes or additions.
> 
> [] +1
> [] +/-0
> [] -1
> 
> My +1 is nonbinding for this vote, so we need three okeydokeys from vested
> PMC members.
> 
> Vote will close Saturday at 22:00 PDT.
> 
> Thanks,
> --Ben
> 


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


Re: [VOTE] Release Email 1.1

Posted by Emmanuel Bourg <eb...@apache.org>.
*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.org/pub/mirrors/maven2/org/apache/commons/commons-email/1.1/ 
> 
> 
> Emmanuel Bourg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

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


Re: [VOTE] Release Email 1.1

Posted by Emmanuel Bourg <eb...@apache.org>.
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


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


Re: [VOTE] Release Email 1.1

Posted by Ben Speakmon <bs...@apache.org>.
> 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 includes a /lib directory with some
> jars that the README says are not needed by the maven build.
> Shouldn't these be removed from the distro?  Both mvn and ant builds
> seem to work without this directory.  This is a showstopper if the
> license is not compatible.


I'll double-check this; if I'm right about the new ant build, they're not
necessary anymore.

2) What is the difference between maven-build.xml and build.xml?  Both
> seem to work.  Maybe one should be removed?  Could be I am missing
> something here.


They came from the maven 2 ant file generator. The idea is that
user-specific customizations go in the build.xml while the
maven-build.xmlis read-only. I thought it was a little silly myself,
but it was much easier
to regenerate the ant files than try to fix the old autogenerated one.
Perhaps a note in the build instructions?

3) The manifest has built-by attribute "ben".  I don't know if if is
> possible to override the built-by using m2, but it would be good to
> make this "bspeakmon. "


Good idea. I'm sure there's an option for it somewhere.

4) Opinions vary on this, but at least some of us think that it is
> best to build the release binary jars using the lowest supported jdk -
> which in this case should be 1.4.  Looks like the binary was built
> using 1.6.


I'm not that concerned about it personally, but it does look better to those
who care deeply about it if I use the target JDK. Since I'm doing another
build anyway, it's no biggie to switch.

Sigs and hashes check fine.  We need to make sure to update
> http://www.apache.org/dist/commons/KEYS to add your key prior to
> release.  Do we just copy this from SVN?  You should also publish your
> key to some keyservers and get it signed.


Will do. Henri should have a signed copy of my key as well.

Re: [VOTE] Release Email 1.1

Posted by Phil Steitz <ph...@gmail.com>.
On 9/19/07, Ben Speakmon <bs...@apache.org> 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 new
> features, I'd like to put it to a vote.
>
> Artifacts:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/
>
> Staged site:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/site/
>
> Release notes:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/RELEASE-NOTES.txt
>
> clirr:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/clirr.txt
>
> rat:
> http://people.apache.org/~bspeakmon/commons-email-1.1-RC1/rat.txt
>
> There is one breaking change to point out: the protected field
> HtmlEmail.inlineImages was changed from a List to a Map. This was done
> because the original implementation didn't work correctly. There's no reason
> why this field can't be private, since the class isn't designed for
> extension. I figured that changing the type and not the visibility would
> give that one guy who did subclass the chance to find out and fix it. Aside
> from this, all other changes are fixes or additions.
>

Nice work!

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?

A few more observations.

1) I notice that the src distro includes a /lib directory with some
jars that the README says are not needed by the maven build.
Shouldn't these be removed from the distro?  Both mvn and ant builds
seem to work without this directory.  This is a showstopper if the
license is not compatible.

2) What is the difference between maven-build.xml and build.xml?  Both
seem to work.  Maybe one should be removed?  Could be I am missing
something here.

3) The manifest has built-by attribute "ben".  I don't know if if is
possible to override the built-by using m2, but it would be good to
make this "bspeakmon. "

4) Opinions vary on this, but at least some of us think that it is
best to build the release binary jars using the lowest supported jdk -
which in this case should be 1.4.  Looks like the binary was built
using 1.6.

Sigs and hashes check fine.  We need to make sure to update
http://www.apache.org/dist/commons/KEYS to add your key prior to
release.  Do we just copy this from SVN?  You should also publish your
key to some keyservers and get it signed.

Phil

> [] +1
> [] +/-0
> [] -1
>
> My +1 is nonbinding for this vote, so we need three okeydokeys from vested
> PMC members.
>
> Vote will close Saturday at 22:00 PDT.
>
> Thanks,
> --Ben
>

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


Re: [VOTE] Release Email 1.1

Posted by Rahul Akolkar <ra...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org