commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: Release of commons-cli?
Date Thu, 29 May 2008 15:50:38 GMT
On Wed, May 28, 2008 at 9:01 AM, Russel Winder
<> 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

> 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:

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.


> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message