On Wed, Oct 6, 2010 at 5:48 PM, Paul Benedict <pbened...@apache.org> wrote: > Let's say IO went out as 2.0 and it was binary compatible. There are > enhancements planned for for 2.x that would break compatibility. Is > that still okay?
No - if/when IO breaks binary compatibility, then IMO there will be a package name change and major version. I'll sort out JIRA if/when this release is out Niall > I find it odd we would strive for 2.0 to be binary > compatible, but allow 2.x not to be. > > Paul > > On Wed, Oct 6, 2010 at 11:34 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> Hi guys, >> >> Niall Pemberton wrote: >> >>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <ja...@carmanconsulting.com> >>> wrote: >>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton >>>> <niall.pember...@gmail.com> wrote: >>>>> >>>>> There are four people who think 2.0 (Stephen and myself in this thread >>>>> and Sebb and Dennis in the previous thread back in March[1]) that >>>>> think it should be 2.0. So far there are five who think 1.5 (Jörg, >>>>> James, Michael, Paul & Matt). So people disagree. Its OK to have a >>>>> massive debate on this, but I would much rather spend my time on >>>>> something less trivial than version number ideology. >>>>> >>>> >>>> The problem is that you're causing some inconsistency. Bumping major >>>> version numbers without changing package name/artifactId doesn't go >>>> along with what Apache Commons has come up with as a "best practice" >>>> or sorts. Jumping to 2.0 also carries with it an assumption of binary >>>> incompatibility for most users. >>> >>> Commons is a federation. IMO Its not a one-size-fits all with a set of >>> rules to make all components adhere to. We do different things on >>> different projects and generally leave decisions up to the developers >>> on that component. >>> >>> I disagree completely with your assertions about version numbers: >>> >>> * We have some very widely used components that we don't break binary >>> compatibilty without a package name change (e.g. Lang, Logging, >>> Collections, IO, DBCP, BeanUtils to name some). However there are >>> other components where I think its OK to do that (for example >>> Validator 1.2.0 did removing deprecated items) >>> http://markmail.org/message/omy4kiacas53pvfx >> >> We have the versioning guidelines >> (http://commons.apache.org/releases/versioning.html#Release_Types) and it is >> - as Sebastian stated - completely valid to increase the major version if >> substantially improvements have been made. Due to the compatible nature of >> this release it felt simply strange to me and I wanted to start the >> discussion before a vote is started. >> >>> * I agree with the practice that *if* a component decides to change >>> the package name, it should be a *major* version. But that is >>> different from a "a major version number therefore means a package >>> rename" and that is a something I've don't remember anyone even >>> suggesting here. >>> >>> I also don't agree with your assertion "assumption of binary >>> incompatibility for most users" - the vast majority of users never >>> even visit us here and are unaware of our practices. I bet that most >>> users either try-it-out before committing to and upgrade and if >>> they're concerned, go look for the release notes - which are very >>> clear on this. >> >> However, if we do not get a consensus on this topic, Niall is free as >> release manager to continue, because he's nevertheless in line with the >> versioning guidelines. Everyone, who disagrees including myself can take the >> role for the next release (of any component). >> >> - Jörg >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
