commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsoftware.com>
Subject RE: [VOTE] Release CLI 1.1
Date Wed, 13 Jun 2007 02:31:44 GMT
> 1) Why not deprecate the public fields in HelpFormatter rather than
> making them private?

Or calling the release 2.0 with the understanding that a breaking compatibility is under the
charter of major release.

Thank you,
Gary

> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> Sent: Tuesday, June 12, 2007 7:16 PM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] Release CLI 1.1
>
> On 6/12/07, Henri Yandell <flamefew@gmail.com> wrote:
> > I think we're finally ready for CLI 1.1 to be released:
> >
> > http://people.apache.org/~bayard/commons-cli/1.0-rc1/
> >
> > with the site in:
> >
> > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/
> >
> > One quirk to note. The site is from trunk while the release is from
> > the 1.0.x branch (needs renaming).
> >
> > [ ] +1, quick release before it's 5 years since 1.0
> > [ ] -1, let's go for 6 years
>
> Theres too much on the CLIRR report IMO for this to be a bug fix
> release - I'm not that familiar with CLI but most (all?) don't seem
> necessary for this 1.1 release
>
> 1) Why not deprecate the public fields in HelpFormatter rather than
> making them private?
> 2) IMO removing the Cloneable interface from Option seems just as bad
> as leaving it in broken (and actually fixing it doesn't seem that
> difficult).
> 3) Why not deprecate the public addValue() method in Option rather
> than changing the visibility to package (and removing boolean return
> type)?
> 4) Could an additional interface that extends CommandLineParser that
> adds the new methods have not been introduced instead?
>
> I don't subscribe to the "never break backwards compatibility" - but I
> do believe in deprecate/remove cycles and trying to retain
> compatibility in bug fix releases. For me there's too much in this
> one. If it was just the CommandLineParser - which does seem to offer
> benefits to the user - and is mitigated by the fact that (hopefully)
> most people will have extended Parser and be unaffected, then I would
> probably buy that argument.
>
> Niall
>
> > 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


Mime
View raw message