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. 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. 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. > > Can I suggest that > > 2.0-SNAPSHOT could happily be released into the snapshot repository to > > give things a kick start? > > I'll get that done. Been a while since I remember doing a snapshot > release so have asked how we do that nowadays on [EMAIL PROTECTED] I have no idea about the Apache system but at Codehaus deployments go to the snapshot repository automatically if the version number has -SNAPSHOT at the end. For the Gant project (which let's be honest is the only one I actually know about), it all Just Works (tm). > > Alternatively, the decision to move to 2.0 could be rescinded and 1.x > > treated as the mainline. However, I had understood that the 1.x > > architecture was fundamentally inferior to the 2.x architecture. > > That's what they say. As a user I didn't feel too excited about the 2.x API. 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. It would actually be interesting to know why the 2.x developers effectively abandoned the project. > > I think there is more to CLI-137 than is currently listed. From memory > > (I will try and dig up the test cases) processing multiple options (e.g. > > -D) fails to work in CLI 1.1. So unless someone has fixed that I would > > deem 1.2 as unusable just as 1.1 is :-( > > Test cases much appreciated :) I'll have a look tomorrow to see if I can turn all my rantings and bad examples into some proper test cases. > > > This is actually an opportune moment for something to happen with > > COmmons CLI as there are gumblings again about still having to use CLI > > 1.0 for Groovy. Current favourite is to switch to a new CLI package > > that has some energy, i.e. someone is actually working on it :-) > > Currently mooted to move to are JSAP or JOpt. > > > > If however there was a Commons CLI 1.2 and it fixed the bugs we found in > > the Groovy project that mean that 1.1 is basically broken and unusable, > > then that would be great. Shifting a version of a package is easier > > than shifting packages. > > I don't see why not for a 1.2 release that fixed the bugs. All I got > from the previous problems was that unfortunately .hasArg had to be > changed to .hasArgs, so more test cases for the problems would be > great. I was focused on JIRA issues rather than the mailing list > archives though. There is the problem behind that that there seemed to be errors in the implementation which meant that multiple option occurrences actually caused total chaos. Also the PosixParser and GnuParser both behave differently to what the documentation says they should do. Again I have rants but I need to turn them into test cases. 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. Switching to 2.0 is predicated on 2.1 being scheduled and 2.0-SNAPSHOT hitting the Maven repository. -- Russel. ==================================================== Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
