Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Well, that's just my point. They shouldn't have to put in an effort because it's a point release - it should be a drop-in replacement. Henri Yandell wrote: Not a problem though. Anyone who has that setup will definitely put in the effort to find out why it's deprecated and adjust their code. Hen On 6/21/07, Dennis Lundberg [EMAIL PROTECTED] wrote: I can see one reason for not deprecating stuff in a point release. If someone is really concerned about deprecation warnings, I would imagine that they could set up their build system to fail if there are deprecation warnings. A point release should be a drop in replacement. So if you add deprecations to a point release it could, in this scenario, possibly fail someone's build if they upgrade commons-io from 1.3.1 to 1.3.2. Henri Yandell wrote: Sorry for being slow on this one. I'm with Jochen and Joerg in not getting why deprecation would indicate a minor release and not be allowed in a bugfix release. Sure it sucks that a new class is immediately being deprecated, but better to get such things out there now rather than waiting. Hen On 6/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
What is a minor x.x.x release for? Consider the recent modeler vote for 2.0.1. This will probably go through very quickly, and that is because the change involved is tiny and non controversial. That is what these releases are for IMHO - fixing up release process mistakes and major bugs. As a general rule, commons has always preferred x.x releases to fix bugs. Especially bugs which involve the creation of a new class, and the deprecation of an entire existing class. Personally, I expect to be able to drop in a x.x.x without thought. In this case, a LOT of thought is being asked to remove the deprecation. (Although deprecation doesn't require immediate action, many shops require that) To change an application which relies on a static utility class (easy to use, available directly from anywhere), to one using a bean which has to be manually managed (create, delete, pass around to point of use) is a big deal. That doesn't come anywhere close to my definition of an x.x.x release. This isn't about deprecation per se, but the scale of change. I would accept a deprecation of a single method in a non-major part of the library in a x.x.x, but not a whole class where the way to solve the deprecation is so hard. My opinion is that this should be a 1.4. However, if you wish to release more quickly, I offered the option of removing the @deprecated from the static utility class for 1.3.2. Should I do the work? Well, I generally take the view that the RM is in control of the sourcebase during the release period. We also haven't taken a decision on which of the two approaches to take. Finally, as I have previously indicated, my involvement in commons is currently fairly limited due to my JSR310 commitments. However, should you request that I make a change here (the group should decide which change), then I will try and fit it in. Stephen Jochen Wiedmann wrote: On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Sorry for being slow on this one. I'm with Jochen and Joerg in not getting why deprecation would indicate a minor release and not be allowed in a bugfix release. Sure it sucks that a new class is immediately being deprecated, but better to get such things out there now rather than waiting. Hen On 6/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
I can see one reason for not deprecating stuff in a point release. If someone is really concerned about deprecation warnings, I would imagine that they could set up their build system to fail if there are deprecation warnings. A point release should be a drop in replacement. So if you add deprecations to a point release it could, in this scenario, possibly fail someone's build if they upgrade commons-io from 1.3.1 to 1.3.2. Henri Yandell wrote: Sorry for being slow on this one. I'm with Jochen and Joerg in not getting why deprecation would indicate a minor release and not be allowed in a bugfix release. Sure it sucks that a new class is immediately being deprecated, but better to get such things out there now rather than waiting. Hen On 6/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Not a problem though. Anyone who has that setup will definitely put in the effort to find out why it's deprecated and adjust their code. Hen On 6/21/07, Dennis Lundberg [EMAIL PROTECTED] wrote: I can see one reason for not deprecating stuff in a point release. If someone is really concerned about deprecation warnings, I would imagine that they could set up their build system to fail if there are deprecation warnings. A point release should be a drop in replacement. So if you add deprecations to a point release it could, in this scenario, possibly fail someone's build if they upgrade commons-io from 1.3.1 to 1.3.2. Henri Yandell wrote: Sorry for being slow on this one. I'm with Jochen and Joerg in not getting why deprecation would indicate a minor release and not be allowed in a bugfix release. Sure it sucks that a new class is immediately being deprecated, but better to get such things out there now rather than waiting. Hen On 6/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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: [RESULT] 3rd attempt: Release commons-io 1.3.2
I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. 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: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Jochen Wiedmann jochen.wiedmann at gmail.com writes: The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. Amen. Especially since the official versioning guidelines [1] consider deprecation as a fully compatible change while a point release only requires interface compatibility. What's actually the reasoning to demand a minor release because of a deprecation? Joerg [1] http://jakarta.apache.org/commons/releases/versioning.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/20/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. My 2 cents... Commons operates in a slightly different way than most projects. On other projects the group of developers have a shared goal on the code they develop and release. Here at commons we have a set of components that on their own probably couldn't muster enough community to pass a release vote and rely on the goodwill of other developers (that probably have no interest in the component) to check out the RC and vote. Speaking for myself I have always appreciated people taking the time to help me get releases out and - since I don't think I can take it for granted - always tried to resolve the issues people have raised. As an eco-system this seems to work for small components with few developers. If we start to react to people reviewing as being a PITA or ignoring comments - then one likely reaction is for people to stop doing reviews (and casting a vote) - then our eco-system starts to break down. On the actual issue - I don't have a problem with deprecating in a minor version (IMO the real issue is at what point deprecated code can be removed) - Stephen does though, but it is down to you(the RM) whether you chose to keep him happy or release as it is. Niall Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] 3rd attempt: Release commons-io 1.3.2
Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. On 6/20/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit.
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/19/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself snip/ And +1 from Gary in another thread [1] -- though in a subsequent post in the same thread he does express some interest in having the version number be 1.4. -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. snap/ Correct, it isn't a veto. In this case, it is upto you (being the RM) to decide whether to go ahead with putting the bits on the mirrors etc. since you have the required votes. I did not understand your comment about the version number [2] as it relates to whether deprecations should preclude release++ from being a point release. Regardless of what you choose to do here, we should (collectively) form an opinion and clarify this in the versioning guide for future reference. I am of the opinion that it shouldn't be a point release. -Rahul [1] http://www.nabble.com/RE%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd-attempt%3A-Release-commons-io-1.3.2%29-p11091530.html [2] http://www.nabble.com/Re%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd-attempt%3A-Release-commons-io-1.3.2%29-p11093009.html Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] 3rd attempt: Release commons-io 1.3.2
Right +1 from me as noted in [1]. Indeed I did comment about maintenance releases needing to be binary compatible without new features as Apache guidelines note. In this case, I am happy to let the release manager make the call. I am also happy with the XP release early, release often. I think that as long as we document what we are doing in this case, and why, in the release notes, we should be ok. These release number guidelines are important and perhaps it is OK in this case if we can guarantee that nothing will break previous 1.3.x releases (1.3, 1.3.1). It sure does not seem that this should not break anything unless someone is compiling code and has deprecation usage configured as a compile error! Yikes. I think you can do that in Eclipse... Thank you, Gary -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 8:45 PM To: Jakarta Commons Developers List Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 On 6/19/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself snip/ And +1 from Gary in another thread [1] -- though in a subsequent post in the same thread he does express some interest in having the version number be 1.4. -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. snap/ Correct, it isn't a veto. In this case, it is upto you (being the RM) to decide whether to go ahead with putting the bits on the mirrors etc. since you have the required votes. I did not understand your comment about the version number [2] as it relates to whether deprecations should preclude release++ from being a point release. Regardless of what you choose to do here, we should (collectively) form an opinion and clarify this in the versioning guide for future reference. I am of the opinion that it shouldn't be a point release. -Rahul [1] http://www.nabble.com/RE%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd- attempt%3A-Release-commons-io-1.3.2%29-p11091530.html [2] http://www.nabble.com/Re%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd- attempt%3A-Release-commons-io-1.3.2%29-p11093009.html Thanks, Jochen - 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: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
