You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/04/15 03:03:52 UTC

[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


Re: [lang] next version etc

Posted by Henri Yandell <fl...@gmail.com>.
Summarising the 25 remaining open issues:

Debatable:

29692 - I think a lang.text.Indenter would be valuable.
(33825), 38800 - DateRange class. Two separate offerings of this
class. What are the problems with having this? What are the hidden
bugs?

Remaining issue for next release:

30184 - CompositeFormat
33401 - <check>
34284 - NPE in EqualsBuilder
34351 - ClassUtils.getPublicMethod
35588 - text.VariableStuff
36061 - Error in ToStringBuilder
36873 - text.VariableStuff
37385 - Improve javadoc for EscapeUtils
38569 - StringEscapeUtils amphersand bug.
39254 - Expose DateIterator or add method
39315 - New method for EqualsBuilder
37499 - Improve parseDate API

The following seem to involve significantly more time than the above -
still could go in next release but time needs to be spent.

33889 - Split camel case code.
36512 - Enhanced forName
36666 - EnumUtils in 1.5
36925 - ReflectionToStringBuilder and secure fields
37243 - DateUtils.trunc + DST bug
37690 - RandomString + Unicode
38210, 39167 - Complaints about the escapeXml functionality.
38401 - Bug in DurationFormatUtils

Must wait until 3.0:

36886 - Change Exception in Validate.notNull
39322 - Clean up Lang

Hen

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


RE: [lang] next version etc

Posted by James Carman <ja...@carmanconsulting.com>.
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