On 19 February 2015 at 17:13, Stian Soiland-Reyes <st...@apache.org> wrote: > That sounds more like a political release number, I would hope we were > not too political here (except about Apache values :) )
Not necessarily, my example was about requiring a major bump in JVM version. Still binary compatible, but might require users to upgrade their host JVM. Therefore it may be worth flagging the change to end-users via the version number. > Changing the major version number should cause Maven/OSGi t o moan if > project A needs say bcel 5.1 and another tries to pull in 6.0 - that > would be the purpose of the major version number change. AFAIK Maven does not do that. OSGi may do so; I don't know. > If there is no binary incompatibility introduced, then it seems > pointless to enforce such warnings with a new major version in pom.xml > and friends. What is the evidence that a major bump causes warnings? > The nature of the project matters - say an application which is not > dependended on as a library would be more natural to bump the major > version when there are significant UI or feature changes. Yes, and such projects don't really need to pay much attention to binary compatibility either. > > (This is a very relevant discussion as another thread was just talking > about updating https://commons.apache.org/releases/versioning.html to > relate to SemVer) > > > On 19 February 2015 at 15:38, Emmanuel Bourg <ebo...@apache.org> wrote: >> Le 19/02/2015 16:29, sebb a écrit : >> >>> However, according to SemVer one should bump major version if and only >>> if breaking compat. >>> It's only recently that Commons has started discussing whether to use >>> strict SemVer or not; I don't think it has been agreed for all >>> components. >> >> SemVer provides sane guidelines but I wouldn't follow it religiously. In >> my opinion a major version bump is ok even if the compatibility is >> preserved, it can denote major improvements like the ones staged for >> BCEL 6.0. +1 >> >> Emmanuel Bourg >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating) > http://orcid.org/0000-0001-9842-9718 > > --------------------------------------------------------------------- > 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