commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [lang] next version etc
Date Sun, 16 Apr 2006 03:46:23 GMT
3.0 vs. 2.2?  

I say let's do both!  Let's release 2.2 with the new features and quickly
release 3.0 with the deprecated stuff removed/cleaned up (no new features).
That way, we're able to give the new features to folks who also need the
deprecated stuff.  But, we're also able to "slim down" a bit immediately
thereafter.


-----Original Message-----
From: Henri Yandell [mailto:flamefew@gmail.com] 
Sent: Friday, April 14, 2006 9:04 PM
To: Jakarta Commons Developers List
Subject: [lang] next version etc

I want to do something fun...so how about a Lang release.....

First up;  2.2 or 3.0?  It would be nice to have one without enum and
the other deprecated bits.

Second up; text? I think it needs to go into our next version
regardless of version number, or we need to decide to drop it.

Third, bugs. Here're my thoughts:

20015: WONTIFX? Gary's on making Entities public. Looks like a lump of
work to do, is it likely to happen or should we just decide that
Entities shouldn't be public? I don't recall user's being desperate to
use this class.

26659: WONTFIX? Seems like too much in the way of date work - suggest
JODA instead unless a patch is offered.

29692: Patch recently added. Consider and either apply or WONTFIX.

30082: WONTFIX. This is too specific an issue to be putting in Lang I
believe.

30184: Consider for lang.text.

31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated,
or is it simple enough and we can do it?

33102: FIX: On the one hand, it's pretty simple stuff, and we'd have
to support the roll(..) method. On the other hand, user's like this
stuff and it's not hard to add it, even if we overload with Calendar
as well. 4 methods would be needed.

33401: FIX: it's a bit redundant, but I've no reason not to have these
methods available. Any -1s?

33609: FIX. Javadoc needs improving.

33825: WONTFIX. Standard java.time question - is it valuable and
simple, or should we just point to JODA? I'm going to go with WONTFIX
as my default answer on time enhancements.

33889: Unsure. Could be a CharSet enhancement instead of just a camel
case method. Thoughts?

33997: I think this is a useful method - just need to make sure the
implementation is the best possible.

34284: FIX: NullPointer; test and fix.

34351: FIX: I don't see any reason not to try to write Albert's
method. If not obvious when digging into it, then we can WONTFIX.

35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave
the scope of 'simple' to my ignorant brain :)

35588: Part of the lang.text call.

35826: Bring up with [math]. I think it could be in either, not sure I
have the itch to write a BigXxx replacement though.

36061: FIX. Seems simple enough - bug and patches.

36512: FIX. I think there's value for a .forName improvement.

36666: Thoughts? Is it worth putting that inside the Enum code?

36839: WONTFIX: Covered by lang.text.

36873: FIX: Hooked to lang.text; but as a patch is provided I don't
see any reason not to go with that.

36886: FIX: Seems valid. Tied to 2.2 vs 3.0 I think - backwards compat.

36915: WONTFIX: As I've no idea what's actually being said :)

36925: Status Gary?

37243: Time pain :) Thoughts?

37385: DOC. Don't see any problem in saying that apos; isn't included.

37499: WONTFIX. Point to JODA.

37690: FIX. Unit test offered.

38210: Thoughts? Is it undesired?

38401: Examine further. FIX if possible.

38569: FIX. Patch supplied - though might need improvement.

38800: Consider. Either FIX or point to JODA.

38912: No clue or itch on this one. Is it important for us to provide
this? Is it of use to users, or just to other libraries who 50% of the
time don't have a dependency on lang?

39254: Hesitant to offer up more lang.time functionality. Thoughts on this?

39315: Seems worthy of application.


----

There, that was fun... :)

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