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
