On 6/12/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 6/12/07, Henri Yandell <[EMAIL PROTECTED]> 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
It is a minor, rather than bugfix. So I think it's fair to say "Please
recompile". However, also good to keep backwards compat when it's not
too painful.
1) Why not deprecate the public fields in HelpFormatter rather than
making them private?
I think it's a simple enough change for people to adjust to this one
if they discover they've used the public fields. So I'd like to be
bold on this one and not put the public fields back in.
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).
Agreed. It's a pain for someone if they've actually used the clone().
I don't see any great needs to clone options, however someone did
report a bug with it so that would imply that someone wanted to clone.
So +1 to looking into fixing this:
http://issues.apache.org/jira/browse/CLI-21
3) Why not deprecate the public addValue() method in Option rather
than changing the visibility to package (and removing boolean return
type)?
I think this was a recent change that Brian and I made (need to
check). That method should not, not, not, be called by a user. Option
classes are immutable-ish, but behind the scenes the code mutates
them. So definitely want to break people who are using this.
4) Could an additional interface that extends CommandLineParser that
adds the new methods have not been introduced instead?
Dunno. Again - need to delve into history and try and estimate
intentions. There are three parser implementations in CLI and they all
extend Parser (the abstract class). I think it's a pretty safe bet
that implementing the interface directly is going to be rare (tending
to zero).
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.
My general subscription is that I want to break it if it's bug
related, and deprecate it if the removal is just policy or trivial
(ie: renaming, package moving etc). We do need to sort out the clone
one, others I think can stay (consensus pending).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
