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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
