On Wed, May 28, 2008 at 9:01 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > Hen, > > On Wed, 2008-05-28 at 02:01 -0700, Henri Yandell wrote: >> On Wed, May 28, 2008 at 12:30 AM, Russel Winder >> > What is needed to move 2.0 to release? Given that the policy decision >> > was made to shift any new activity to 2.0, saying 2.0 is defunct is >> > equivalent to saying Commons CLI is defunct. >> >> No life happened on 2.0. I've been applying patches that show up for >> the 1.x branch, just because. :) > > I think this is a chicken and egg problem. No-one is doing anything > proactive at the minute because the Commons CLI development team is the > empty set. No-one is providing bug reports for 2.x because 2.0 is not > publicly available in any form. > > It is good that you are doing the 1.x patching, but I think a bit of > decisive management is in order. For me the options would appear to be: > > 1. Declare Commons CLI end of life and let it gently disappear. People > will then move to those projects that have activity.
Tempting. Commons has a few libraries that are similarly commonly used and reaching end of life; BeanUtils jumps to mind as a popular yet EOL library. > 2. Declare Commons CLI 2.x the active branch -- even to renaming the > package to cli instead of cli2, put out a snapshot so people can use it > and provide bug reports, nominate a couple of the volunteers to the > development team -- basically use the little interest there is in CLI to > boostrap a more lively community. Oh and schedule a putative release > date for 2.0 and publicize it so that an RC programme can be started. Snapshot done: http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-cli/ Package renaming to cli is unlikely to happen. CLI2 is the active branch now, in terms of declaration, just not in reality. > 3. Declare Commons CLI 2.x a dead branch, revert to 1.x as the only > line of development, make a Maven 2 build for it. Then do exactly the > same as above, get the few volunteers into a formal development team, > announce a release date and begin an RC programme. > > Sorry if I am being a bit over-pushy here but the Commons CLI 1.0 issue > is really annoying a few of the Groovy developers. No prob - I really hadn't grokked the -D bug until the last email. We need to get that fixed. > If there is a compelling reason for the 1.x -> 2.x API change, is there > a document somewhere that explains it? Or is the information trapped in > the heads of the development team who fled the project? I can do a > little to do some analysis and recommendation but not masses. Trapped. > It would actually be interesting to know why the 2.x developers > effectively abandoned the project. Yep. Maybe time for an email, it's been a while since I sent them one. > I have to admit I got bored with trying to sort it all out when I > realized I was totally on my own trying to sort it out. All the Groovy > guys just want to abandon Commons CLI in favour of a package that has > some active development or at least maintenance. An active programme to > release Commons CLI 1.2 and 1.3 would be a boon and save us a lot of > hassle and work. Maintenance releases here are reactive - ie) there's no reason for a 1.3 yet as all bugs should be fixable in a 1.2 release. > Switching to 2.0 is predicated on 2.1 being scheduled > and 2.0-SNAPSHOT hitting the Maven repository. 2.0 schedule = when all bugs in the 2.0 JIRA project are resolved or moved to 2.1. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
