Am 14.07.2011 21:43, schrieb Matt Benson:
On Thu, Jul 14, 2011 at 2:36 PM, Henri Yandell<flame...@gmail.com> wrote:
On Thu, Jul 14, 2011 at 12:12 PM, Oliver Heger
<oliver.he...@oliver-heger.de> wrote:
Am 14.07.2011 21:01, schrieb Matt Benson:
On Thu, Jul 14, 2011 at 1:54 PM, Gary Gregory<garydgreg...@gmail.com>
wrote:
-1, let's pick up the committed fix for
https://issues.apache.org/jira/browse/LANG-720
I recall seeing traffic in the escape/unescape area so it makes sense to
polish this new code as much as possible IMO.
Potential argument against: it's new code, and only broken for
surrogate planes, so won't affect that many users.
Potential argument for: it's new code, and releasing it broken may
harm its reputation from the outset.
-0 to the release from me.
Well, if the fix is already in SVN, I would also prefer to include it in the
release. I hope, Hen does not loose his patience...
I have a 3 month old, a 3 year old and a 6 year old. There are entire
worlds left of my patience to be explored before you guys even get
close to it being lost :)
That said - if it's not a binary compatibility issue I would prefer to
release now and then release again with a 3.0.1. My firm intent is to
keep shoving releases at commons-dev@ as fast as it can stomach them.
I can promise that if we roll again there will be another minor bug
[for example there's already 11 bugs in 3.x, with
https://issues.apache.org/jira/browse/LANG-708 being one that needs
fixing quickly in a bugfix release].
If we're releasing early and often I retract my quasi-objection,
though I haven't yet eyeballed the RC such that I can conscientiously
give a +1 either. And I really don't mind RMing 3.0.x either, dearth
of round tuits notwithstanding, but I need somebody to hold my hand
and show me that the big bad Maven isn't going to get me.
I also agree with Hen's argument. Just checking the release and going to
vote in some minutes.
Oliver
Matt
Hen
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
