Re: [VOTE] Release CLI 1.1 (3rd RC)
On 7/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote: [X] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and Sorry about that. -Rahul my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
+1 Phil On 7/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
+1 Henri Yandell wrote: > I've updated the release notes to match the website page: > > http://people.apache.org/~bayard/commons-cli/1.0-rc3/ > > with the site in: > > http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ > > One quirk to note. The site is from trunk while the release is from > the 1.0.x branch. > > [ ] +1, before 6 years since 1.0 arrives > [ ] -1, we can make 6 years > > --- > > The only changes to svn are Rahul's NOTICE fix for our TLP change and > my updating the RELEASE-NOTES.txt with the latest information. So I > plan to consider any existing +1s for the RC2 as applying to this (ie: > Don't revote unless you want to). > > Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
I think I +1'd this last time, but just in case: +1. On 7/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit.
Re: [VOTE] Release CLI 1.1 (3rd RC)
I'm +1 btw :) Hen On 7/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release CLI 1.1 (3rd RC)
What's wrong with the unsubscribe service? Once you get on this list, you can never get off!!! -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 04, 2007 10:02 PM To: Jakarta Commons Developers List Subject: [VOTE] Release CLI 1.1 (3rd RC) I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release CLI 1.1 (3rd RC)
I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (RC2)
+1. Looks good. On 7/1/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I believe the RC1 issues have been taken care of, so here goes with a second try: http://people.apache.org/~bayard/commons-cli/1.0-rc2/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit.
Re: [VOTE] Release CLI 1.1 (RC2)
+1 Builds and runs tests on my compiler zoo. - Jörg Henri Yandell wrote: > I believe the RC1 issues have been taken care of, so here goes with a > second try: > > http://people.apache.org/~bayard/commons-cli/1.0-rc2/ > > with the site in: > > http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/ > > One quirk to note. The site is from trunk while the release is from > the 1.0.x branch. > > [ ] +1, before 6 years since 1.0 arrives > [ ] -1, we can make 6 years > > > Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (RC2)
On 7/1/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: +1 from me Would be nice to have more keys in the KEYS file though. Thinking about it - don't even need the KEYS file anymore. We merged all the Commons ones together. So now testing should involve getting the central KEYS file and making sure the RM has their key in there. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (RC2)
On 7/1/07, Oliver Heger <[EMAIL PROTECTED]> wrote: +1 from me. Some minor remarks: - When building with maven, in the manifest of the resulting jar some entries are duplicated with different values. I get: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: hen Package: org.apache.commons Build-Jdk: 1.4.2_12 Extension-Name: commons-cli Specification-Title: Jakarta Commons CLI Specification-Vendor: Apache Software Foundation Implementation-Title: Jakarta Commons CLI Implementation-Vendor: Apache Software Foundation Implementation-Version: 1.1 Implementation-Vendor-Id: org.apache X-Compile-Source-JDK: 1.3 X-Compile-Target-JDK: 1.3 Specification-Version: 1.1 - When building with ant the resulting jar does not contain LICENSE and the manifest is pretty poor. Not too bothered. A question about the release notes: Are they in line with the clirr report? They talk about some binary incompatibilities, but the report is clean. Curses. I updated the release notes in the site, but not the text file. Guess I need to do an RC3. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (RC2)
+1 from me. Some minor remarks: - When building with maven, in the manifest of the resulting jar some entries are duplicated with different values. - When building with ant the resulting jar does not contain LICENSE and the manifest is pretty poor. A question about the release notes: Are they in line with the clirr report? They talk about some binary incompatibilities, but the report is clean. Oliver Henri Yandell wrote: I believe the RC1 issues have been taken care of, so here goes with a second try: http://people.apache.org/~bayard/commons-cli/1.0-rc2/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (RC2)
+1 from me Would be nice to have more keys in the KEYS file though. On 30.06.2007, at 20:38, Henri Yandell wrote: I believe the RC1 issues have been taken care of, so here goes with a second try: http://people.apache.org/~bayard/commons-cli/1.0-rc2/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release CLI 1.1 (RC2)
I believe the RC1 issues have been taken care of, so here goes with a second try: http://people.apache.org/~bayard/commons-cli/1.0-rc2/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Rahul Akolkar gmail.com> writes: > We still do: > > http://jakarta.apache.org/commons/releases/versioning.html Regarding deprecation: It is considered a fully compatible change. So you can actually deprecate at any point and don't need to postpone it a next release of a particular type. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
However the addValue is still one that I think needs to be considered as a special case. People should NOT use that method. It screws things up. We could keep the public method and change it to throw a RuntimeException of some kind; and then use a package private method with a different name. How does that sound? I like, but also deprecate the method and explain in the deprecation warning why it's evil and why it's only there for compatibility (a la the doc for Thread.stop() in the JDK). Have the RuntimeException include the deprecation warning in its message too.
Re: [VOTE] Release CLI 1.1
On 6/13/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: - Original Message From: Henri Yandell <[EMAIL PROTECTED]> > > 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 to the principle, and thus -1 to the release as is. See the versioning thread for more details. Given all the agreement on the other thread *sulks like a 2 year old* Time to figure out the history of these changes then. Looks like Brian and Ben have got the clone one moving along. Fields will be easy to put back. The interface will be weird. However the addValue is still one that I think needs to be considered as a special case. People should NOT use that method. It screws things up. We could keep the public method and change it to throw a RuntimeException of some kind; and then use a package private method with a different name. How does that sound? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
+1, I would also like to see commons project releases say with each release if they adhere to this charter (as an extra checks and balances thing) Thank you, Gary > -Original Message- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 12, 2007 11:19 PM > To: Jakarta Commons Developers List > Subject: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1 > > Sorry, but I have to agree with Niall on this - needs to be 2.0 with > the incompatible changes - and I would like very much for us to agree > once and for all on some versioning/deprecation rules. We seem to > have lost the old versioning guidelines (unless I am senile, we used > to have these on the commons or Jakarta pages somewhere). Apart from > 0), which is a conservative but worth-considering-carefully PoV, the > rules below are more or less what we have been adhering to over the > last several years in commons and I would like to propose that we > standardize on them. If all are OK, I will gin up a versioning page. > A very good one, which is pretty much a C version of what I am > proposing below, is http://apr.apache.org/versioning.html. > > 0) Never break backward source or binary compatibility - i.e., when > you need to, change the package name. > 1) 0 is going to have to fail sometimes for practical reasons. When > it does, fall back to > a) no source, binary or semantic incompatibilities or deprecations > introduced in a x.y.z release > b) no source or binary incompatibilities in an x.y release, but > deprecations and semantic changes allowed > c) no removals without prior deprecations, but these and other > backward incompatible changes allowed in x.0 releases. > > This means that the [cli] release with the current changes would need to be > 2.0. > > Phil > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
On 6/13/07, Phil Steitz <[EMAIL PROTECTED]> wrote: Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). We still do: http://jakarta.apache.org/commons/releases/versioning.html -Rahul Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Phil Steitz gmail.com> writes: > a) no source, binary or semantic incompatibilities or deprecations > introduced in a x.y.z release I really wonder what's the problem with deprecations since they don't have any influence on compatibility. I'd guess there is always a reason for deprecating something. Not doing so despite that reason is most careless IMO since you encourage users to use that commons' code despite knowing better that it is a bad choice regarding future compatibility of the user's code. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
- Original Message From: Henri Yandell <[EMAIL PROTECTED]> > > 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 to the principle, and thus -1 to the release as is. See the versioning thread for more details. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
- Original Message From: Phil Steitz <[EMAIL PROTECTED]> > I would like very much for us to agree > once and for all on some versioning/deprecation rules. Exactly the thread I was about to start :-) > We seem to > have lost the old versioning guidelines (unless I am senile, we used > to have these on the commons or Jakarta pages somewhere). Apart from > 0), which is a conservative but worth-considering-carefully PoV, the > rules below are more or less what we have been adhering to over the > last several years in commons and I would like to propose that we > standardize on them. If all are OK, I will gin up a versioning page. > A very good one, which is pretty much a C version of what I am > proposing below, is http://apr.apache.org/versioning.html. > > 0) Never break backward source or binary compatibility - i.e., when > you need to, change the package name. > > 1) 0 is going to have to fail sometimes for practical reasons. When > it does, fall back to > a) no source, binary or semantic incompatibilities or deprecations > introduced in a x.y.z release > b) no source or binary incompatibilities in an x.y release, but > deprecations and semantic changes allowed > c) no removals without prior deprecations, but these and other > backward incompatible changes allowed in x.0 releases. This is pretty much my thinking, except that I want to tighten 1c - "no removals without prior deprecations allowed in x.0 releases. Source and binary backward incompatible changes may be considered at the edges of the API, but not the core." (We have to be strict as many, many other open source projects rely on commons, and they can't be re-compiled just because of commons. Commons has to act and behave close to the JDK on incompatibilities). Commons needs clarity on this subject, and having it should speed up releases and voting. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
- Original Message From: Phil Steitz <[EMAIL PROTECTED]> > I would like very much for us to agree > once and for all on some versioning/deprecation rules. Exactly the thread I was about to start :-) > We seem to > have lost the old versioning guidelines (unless I am senile, we used > to have these on the commons or Jakarta pages somewhere). Apart from > 0), which is a conservative but worth-considering-carefully PoV, the > rules below are more or less what we have been adhering to over the > last several years in commons and I would like to propose that we > standardize on them. If all are OK, I will gin up a versioning page. > A very good one, which is pretty much a C version of what I am > proposing below, is http://apr.apache.org/versioning.html. > > 0) Never break backward source or binary compatibility - i.e., when > you need to, change the package name. > > 1) 0 is going to have to fail sometimes for practical reasons. When > it does, fall back to > a) no source, binary or semantic incompatibilities or deprecations > introduced in a x.y.z release > b) no source or binary incompatibilities in an x.y release, but > deprecations and semantic changes allowed > c) no removals without prior deprecations, but these and other > backward incompatible changes allowed in x.0 releases. This is pretty much my thinking, except that I want to tighten 1c - "no removals without prior deprecations allowed in x.0 releases. Source and binary backward incompatible changes may be considered at the edges of the API, but not the core." (We have to be strict as many, many other open source projects rely on commons, and they can't be re-compiled just because of commons. Commons has to act and behave close to the JDK on incompatibilities). Commons needs clarity on this subject, and having it should speed up releases and voting. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
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. Seeing how I'm about to go down a similar road with commons-email... I'm okay with requiring a recompile as long as you're not requiring drastic changes in the client source code. 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. Again, works for me as long as it's not onerous. 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. Implementing clone() properly is a pain and hard to get right. If someone really needs distinct copies of Option classes (why?!), I'd suggest providing a copy constructor instead. If compatibility is a really big deal, you could change clone() to call Object.clone(), which throws an exception. Think of it as a gentle hint to the user not to use the method anymore -- and the exception message could also point out the new copy constructor. 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. +1. 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). Concur -- if it's broken, break it; don't wallpaper over it, because some poor sod *will* put his head through it eventually.
Re: [VOTE] Release CLI 1.1
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]
Re: [VOTE] Release CLI 1.1
On 6/12/07, Gary Gregory <[EMAIL PROTECTED]> wrote: > 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. We'll probably want to call CLI2, CLI2 1.0 when it comes out; however CLI1 2.0 is going to confuse things too much if we do that now. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release CLI 1.1
> 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:[EMAIL PROTECTED] > 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 <[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 > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
The fixes on the website are nice an good ...but I don't see that blocking the release at all. From what I can see the artifacts are OK so you got my +1 :) cheers -- Torsten On 13.06.2007, at 00:27, Henri Yandell wrote: On 6/12/07, sebb <[EMAIL PROTECTED]> wrote: On 12/06/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 6/12/07, sebb <[EMAIL PROTECTED]> wrote: > > On 12/06/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/ > > > > There are clirr and jardiff reports here > > > > > with the site in: > > > > > > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ > > > > No mention of the clirr / jardiff reports - seems like it would be > > useful to add them. > > The clirr/jardiff information is summarized in: > > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ upgrading-1.0-to-1.1.html > Yes, but the details would also be useful. Good point. I say 'two methods', but don't detail the methods etc. I could just link the two files up to that page. Bit ugly though. Maybe I should just inline the jardiff one inside the upgrade page. Looks like it's the same info as clirr in this case, and it doesn't run around yelling ERROR etc in ugly text/xml :) Alternatively I could manually pretty the clirr one up. Figuring out how to do all that through Maven1 is more pain than it's worth, especially given that the site doesn't come from the same place as the dist. Ideally I think this is something the repository should be in charge of doing. Feature of Archiva etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 6/12/07, sebb <[EMAIL PROTECTED]> wrote: On 12/06/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 6/12/07, sebb <[EMAIL PROTECTED]> wrote: > > On 12/06/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/ > > > > There are clirr and jardiff reports here > > > > > with the site in: > > > > > > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ > > > > No mention of the clirr / jardiff reports - seems like it would be > > useful to add them. > > The clirr/jardiff information is summarized in: > > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/upgrading-1.0-to-1.1.html > Yes, but the details would also be useful. Good point. I say 'two methods', but don't detail the methods etc. I could just link the two files up to that page. Bit ugly though. Maybe I should just inline the jardiff one inside the upgrade page. Looks like it's the same info as clirr in this case, and it doesn't run around yelling ERROR etc in ugly text/xml :) Alternatively I could manually pretty the clirr one up. Figuring out how to do all that through Maven1 is more pain than it's worth, especially given that the site doesn't come from the same place as the dist. Ideally I think this is something the repository should be in charge of doing. Feature of Archiva etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 12/06/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 6/12/07, sebb <[EMAIL PROTECTED]> wrote: > On 12/06/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/ > > There are clirr and jardiff reports here > > > with the site in: > > > > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ > > No mention of the clirr / jardiff reports - seems like it would be > useful to add them. The clirr/jardiff information is summarized in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/upgrading-1.0-to-1.1.html Yes, but the details would also be useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 6/12/07, sebb <[EMAIL PROTECTED]> wrote: On 12/06/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/ There are clirr and jardiff reports here > with the site in: > > http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ No mention of the clirr / jardiff reports - seems like it would be useful to add them. The clirr/jardiff information is summarized in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/upgrading-1.0-to-1.1.html Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 12/06/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/ There are clirr and jardiff reports here with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ No mention of the clirr / jardiff reports - seems like it would be useful to add them. 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 +1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release CLI 1.1
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 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
