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. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org