commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [lang] What's left for 2.0
Date Mon, 23 Jun 2003 04:01:48 GMT

2.0 time again.

As far as I can tell, all we have left are:

Bug #15082.
  Stephen has done some work here, and suggests making DurationFormatUtils
package scoped for 2.0. +1 from me, anyone against it?

Bug #19331
  Some kind of issue with the builders. Mohan has a good reply here, is it
a real problem or just a feature? Do we kill or solve?

Are there any others that people think should go in?
Are there any other tasks that people are working on or have open?

Hen

On Sun, 15 Jun 2003, Henri Yandell wrote:

>
>
> On Wed, 4 Jun 2003, Gary Gregory wrote:
>
> > We have over the last couple of weeks started "what's left for 2.0" message
> > threads a couple of times, do people here want a 2.0 (or a 2.0 beta first)?
>
> Yep. Time for another one soon. [email I mean]. I'm in favour of just
> going straight to a 2.0 rather than pushing a beta out. I'm not sure that
> reusable libraries as abstract as ours [and not a service like maven,
> tomcat etc] gain much from a beta release.
>
> Apologies for some of the questions coming up and for reopening of old
> emails, I've been gone for 3 weeks.
>
> > Should we consider:
> >
> > (1) IntHashMap as a non-public member of [lang]
> >
> > In for 2.0, or defer to discuss (2)?
>
> This was for Entities.java optimisation? Sounds good to go in.
>
> > (2) "all his other utility code"
> >
> > Does not affect [lang] per se but it is becoming clear that keeping [lang]
> > and [collections] not inter-dependent will introduce duplication of
> > functionality or odd placement of functionality (IntHashMap in lang, not
> > collection). Duplicating code is something I am really not fond of.
>
> I think this is a clear case of a good reason for allowing duplication.
> Optimisation involves lots of yucky things [and rarely anything nice].
> Duplication is a yucky thing, but the optimisation is more important.
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Mime
View raw message