Re: [lang] Time for RC3?

[Henri Yandell <fl...@gmail.com>]

Assuming no one vetos my r1090111 rollback, I think we can go for an
RC4. There are non-API bugs in JIRA, but I'd rather we release with
some bugs and then start fixing/releasing than continually get held
up.

How are you timewise for RC4 Matt? I'm still very kidbound, but
beginning to get some time back.

Hen

On Fri, Jun 17, 2011 at 10:39 PM, Henri Yandell <fl...@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 8:17 PM, Matt Benson <gu...@gmail.com> wrote:
>> On Fri, Jun 17, 2011 at 9:00 PM, Henri Yandell <fl...@gmail.com> wrote:
>>> We had an RC3 vote so shouldn't remove; but I'm very happy if you've
>>> time to do an RC4. I've been managing about enough time to look at the
>>> outstanding issues before I'm back to the diapers.
>>>
>>
>> That's why I asked... I couldn't find the evidence of the RC3 vote for
>> some reason, but I'll take your word for it.
>
> I injected a little confusion by having two threads :)
>
> http://commons.markmail.org/thread/dxmser7yfew37sqb
> http://commons.markmail.org/thread/xk34bmkoz6jctt7g
>
>>> Which is 'what's in JIRA' plus the discussion on the text.translate/Range API.
>>
>> JIRA seems clear, no?  Do we need to wait on the other issue, then?
>
> The thread was:
>
> "[LANG] unnecessary boxing in StringEscapeUtils etc"
>
> Sebb had a complaint re: performance concerns with boxing and Stephen
> suggested a solution, while also considering the performance issue
> minor.
>
> I spent some time a week back playing with the API as I disliked the
> overlap between Range<Integer> and Range<Character>. Autoboxing,
> generics and char-int conversion all get fiddly in the API and not
> nice.
>
> I'm tempted to move the current (Range<Integer>) constructors to a
> static factory method, and then go ahead and release - text.translate
> is not a major part of the Lang API. The reason for doing that is so
> that we can deprecate it later on if desired and not have to worry
> about lots of clashing with the replacement methods.
>
> Hen
>

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