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? 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
