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. Note also that a binary incompatibility involving the external API will also require the package name to be changed (which in turn requires the Maven coordinates to be changed). The package name change is required because there can be only one instance of a class in a single class loader. See discussion here [2] [1] http://commons.apache.org/releases/versioning.html [2] http://wiki.apache.org/commons/MavenGroupIDChange#Classpath_considerations > Feedback appreciated > > Siegfried Goeschl > > --------------------------------------------------------------------- > 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
