On 10 January 2012 20:04, Christian Grobmeier <grobme...@gmail.com> wrote: > On Tue, Jan 10, 2012 at 8:54 PM, sebb <seb...@gmail.com> wrote: >> On 10 January 2012 19:37, Christian Grobmeier <grobme...@gmail.com> wrote: >>> On Tue, Jan 10, 2012 at 5:45 PM, Siegfried Goeschl <sgoes...@gmx.at> wrote: >>>> Hi folks, >>>> >>>> the main reason for the failed vote of commons-email-1.3 is that the >>>> release >>>> is only source but not binary compatible >>>> >>>> +) if you compile your application with the new version everything is fine >>>> +) if you replace simply the JAR the invocation fails >>>> >>>> Is it mandatory that a minor release is binary compatible with the previous >>>> one or do I have to create a new major version? There is a lot of ugly >>>> stuff >>>> (mainly protected member variables) which should be done but is currently >>>> not in the scope of this release. >>>> >>>> Feedback appreciated >>> >>> "Developers must perform a major release whenever the new release is >>> not at least interface-compatible with the previous release." >>> http://commons.apache.org/releases/versioning.html >>> >>> In my opinion if you just add something, you don't need to increment. >> >> Depends what you add. >> If you add a method to an interface, that is binary compatible, but >> not source compatible. > > guidelines say, this is ok with a minor increment: > > Examples of interface-compatible changes include: > > - all fully-compatible changes > - changing a component such that it now depends upon an additional > external library or configuration file > > Examples of changes which are not interface-compatible include: > - changing a public or protected method signature > - changing the default value of an attribute in a behaviour changing way > - removing a class, interface, method or attribute from either the > internal or external interface of the component > > The list is pretty concrete. > It does not say anything on binary compatibility (or i didn't find it).
"Release B is said to be fully-compatible with Release A if B can simply replace A in (nearly) all circumstances and deployments without changing the client code or configuration, and without changing the semantics of any public or protected member. " > Cheers, > Christian > >> >>> If you take something away, you should increment. >> >> Again, depends what you remove. >> But in general that will cause both binary and source incompatibilities. >> >>> See also the section "Fully-Compatible Changes" >>> >>> Btw, I like this very much: http://semver.org/. >>> "Major version X (X.y.z | X > 0) MUST be incremented if any backwards >>> incompatible changes are introduced to the public API" >> >> Agreed. >> >> I think the Commons guidelines are very close to that. >> >>> Cheers >>> Christian >>> >>>> >>>> Siegfried Goeschl >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> >>> -- >>> http://www.grobmeier.de >>> https://www.timeandbill.de >>> >>> --------------------------------------------------------------------- >>> 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 >> > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > --------------------------------------------------------------------- > 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
