commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scolebou...@btopenworld.com
Subject Re: [lang] What's left for 2.0
Date Mon, 23 Jun 2003 09:03:57 GMT
I want to just check CalendarUtils out. Otherwise done.

Plus the NumberUtils min/max question.

Stephen

>  from:    Henri Yandell <bayard@generationjava.com>
>  date:    Mon, 23 Jun 2003 05:01:48
>  to:      commons-dev@jakarta.apache.org
>  subject: Re: [lang] What's left for 2.0
> 
> 
> 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
> 


---------------------------------------------------------------------
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