On 13 January 2012 06:00, Henri Yandell <flame...@gmail.com> wrote: > 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.
What do you mean by bad packaging? > 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. Given that the reason for breaking binary compat. in this example is that we got the API wrong originally, it seems very unfair to choose to fix the problem in a way that causes a potentially insoluble problem for classpaths with multiple dependencies on the component. Especially since there is an alternative that avoids the problem. In both cases the producers of jars that depend on our component are going to have to recompile and re-release in order to use the updated API. There is an additional cost of editting the source to allow for the renamed method/class/package, but compared with recompiling/re-releasing it seems to me that is a relatively small additional cost. > Hen > > --------------------------------------------------------------------- > 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
