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