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). 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
