> -----Original Message----- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Friday, April 14, 2006 6: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.
IMO: 2.2, then 3.0 which removes 'enum' and anything that Java 5/6 complains about. Or... The ticket list below is long and diverse in scope and time needed. A possible "release early, release often" track could be: - Release 2.2 "now", with only critical fixes. Time frame: "now"="weeks". - Release 2.3: implement "easy" fixes and apply no-brainer patches. Time frame: +1 month. - Release 2.4: implement trickier new features that require discussion and time to implement. Time frame: "Months". - Release 3.0: - discuss breaking the API by removing deprecated methods? - discuss changing the base JRE requirement? - discuss deprecating any date/time code that can be replaced with Joda-Time. - builds/works on Java 5? - builds/works on Java 6? Some brief comments on some of the list items: > > 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. I will use text.VariableFormatter in our product. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) I have no plans to use the Str* classes though. > > 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. Release early, release often. Let's leave this one for later. > > 26659: WONTFIX? Seems like too much in the way of date work - suggest > JODA instead unless a patch is offered. I use Joda-Time now. I would even like to propose deprecating DateUtils 'softly' in favor of Joda-Time. I am sure many will not like this at all since Joda-Time is pretty large. > > 29692: Patch recently added. Consider and either apply or WONTFIX. Seems too specific/complex. > > 30082: WONTFIX. This is too specific an issue to be putting in Lang I believe. I agreed. > > 30184: Consider for lang.text. There are no unit tests provided (I know, the class is pretty simple). > > 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. +0. Joda-Time? > > 33401: FIX: it's a bit redundant, but I've no reason not to have these > methods available. Any -1s? Needs better method names IMO. -0. I'm always in favor of release early, release often when there are no unit tests with a code proposal ;) > > 33609: FIX. Javadoc needs improving. Nothing wrong with better docs! :) > > 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. I'm with you: Joda-Time. > > 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. What about commons-math? > > 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. I need text.VariableFormatter. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) > > 35826: Bring up with [math]. I think it could be in either, not sure I > have the itch to write a BigXxx replacement though. Indeed, what does [math] think about that? It would be interesting to know what the [math] folks think about project boundaries for class like that. > > 36061: FIX. Seems simple enough - bug and patches. Some of these bugs might be obsolete. I thought I'd take care of object cycles a while back. Hm, but that might have been for the ReflectionToStringBuilder class, not the ToStringBuilder. > > 36512: FIX. I think there's value for a .forName improvement. Personally, I would only do the super simple stuff, primitives I suppose. Arrays of primitives ok... Basically, anything that you can say in Java code: "int", "int[]". Yeah, that's nice. But I would not want to have us invent a mini-language which the talk of eating up spaces starts to feel like. My vote would be to keep it simple in the first cut, if it is there at all. > > 36666: Thoughts? Is it worth putting that inside the Enum code? It would be nice to be Java 5/6 friendly. > > 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? I like the feature and it is done and it tested. The only thing I can think of is trying to make the API names better (they seem fine now to me). > > 37243: Time pain :) Thoughts? Does Joda-Time deal with this case? > > 37385: DOC. Don't see any problem in saying that apos; isn't included. Agreed, especially if the HTML spec is clear about it and we can point to it. > > 37499: WONTFIX. Point to JODA. +1. > > 37690: FIX. Unit test offered. +1. I love when there's a unit test :) > > 38210: Thoughts? Is it undesired? I wonder if the XML spec has anything to say about that. > > 38401: Examine further. FIX if possible. > > 38569: FIX. Patch supplied - though might need improvement. > > 38800: Consider. Either FIX or point to JODA. IMO: Point to Joda-Time for now. > > 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? Dunno either. Seems nice. Is there an example where lang would eat its own dog food and use it internally? > > 39254: Hesitant to offer up more lang.time functionality. Thoughts on this? > > 39315: Seems worthy of application. > > > ---- > > There, that was fun... :) For a broad enough definition of "fun", yes. ;) Gary > > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
