On Thu, Jan 12, 2012 at 2:52 AM, sebb <seb...@gmail.com> wrote: > On 12 January 2012 08:27, Henri Yandell <flame...@gmail.com> wrote: >> On Tue, Jan 10, 2012 at 10:19 AM, sebb <seb...@gmail.com> wrote: >>> On 10 January 2012 16:45, 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. >>> >>> If the jar is not a drop-in replacement for the previous version, then >>> yes, IMO that requires a major release. [1] >>> The only possible exception might be if the incompatibilities are in >>> internal parts of the API, i.e. classes/methods etc. that are not used >>> externally. >> >> Thinking back on previous discussions, the primary exception has been >> the API itself is the bug and needs changing. >> >> A contrived (and over-simple) example would be: >> >> public void toUppercase(String s); >> >> It'd be better to fix the return type than live with bad API. >> >> Rare, but worth mentioning I thought. > > But that can still cause jar hell. > > If there are multiple jars in the same classloader that use the broken > API, they will all have to be updated at the same time. > May be tricky or impossible even if they are not from different providers. > > That's why binary compatibility is so important.
Bad packaging practices causes jar hell. There's only so far we can go worrying about how our code is used. Part of the reason I felt it worth mentioning is that binary compatibility is not a magic trump card that aces everything else. It's very strongly desirable but not a mandatory absolute. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
