On 11 January 2012 07:16, Siegfried Goeschl <sgoes...@gmx.at> wrote: > Hi folks, > > I think the best for commons-email-1.3 will be reverting the changes of the > setters from > > Email setXXX(arg) > > to > > void setXXX(arg) > > which in turn gives me binary backward compatibility.
There are one or two other changes needed. > I would like to see a > commons-email-1.3 out there which gives me time to work on 2.0 Good plan. You can then make all the other API improvements that require breaking compatibility. > Cheers, > > Siegfried Goeschl > > > > On 10.01.12 19:19, sebb 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. >> >> 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
