On 14 January 2012 08:42, Henri Yandell <flame...@gmail.com> wrote: > On Fri, Jan 13, 2012 at 5:09 AM, sebb <seb...@gmail.com> wrote: >> 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? > > Twofold: > > * Simple situation - people putting multiple versions in blindly. > j2ee.jar is the old classic there, shoving it in without understanding > what it is. That's what I was meaning by bad packaging. > > * More complex - different codebases with differing dependencies. This > is always going to happen and I don't see any difference between a > linkage error due to a difference between 2.5 and 3.0 and a > functionality error due to a difference between 3.0 and 3.0.1. > >>> 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. > > The examples of API screwups I've seen are not ones where those using > them should be. I'm not talking about changing for style, but a method > that flat out is screwed up and doesn't make sense. Anyone relying on > it would be well served by discovering the old version is messed up.
If the API really is unusable, then it is unlikely to have been used (much), so it's unlikely to cause (m)any problems if binary compatibility is broken. But even then, there should ideally be a release where the method is deprecated, before changing it in a subsequent release. However, some examples in this thread were instances of partially wrong design; usable, but not as we would have liked. Changing the API incompatibly to fix that sort of error is likely to cause lots of problems for end users. >> 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. > > It's more fair to force every other file to be repackaged and every > other user to have to deal with it? > > The reality is that we end up causing pain to everyone until we > finally have enough cruft to justify a complete repackage name; then > we hope to get it right followed by more pain to everyone as we lock > down on being a martyr to compatibility. > > 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
