Torsten Curdt wrote:
On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
I suggest marking the offending methods as deprecated for the 1.x
series, and schedule them for removal in the 2.x series.
Well, then let's create a 2.x branch and do a release without the
classes *now*. No problem with that. Then it is communicated and people
can choose. But doing *nothing* just because of binary compatibility is
silly.
Doing nothing because of binary incompatibility is not silly, its
essential. Commons has to be far more extreme than almost any other OSS
project on this point.
In fact, I contend that commons is now in such a position that we can't
make incompatible changes even in major version number releases.
Especially as no one *has* to upgrade libraries. And checking
release notes if you do can't hurt if you upgrade.
Users are forced to upgrade all the time, and thats why they require
backwards compatibility.
For example, if project A is complied against the old [beanutils] jar,
while project B is compiled against the new [beanutils] jar, then it is
impossible to use both project A and project B together. You cannot
physically upgrade the jar file to the one B needs, because A needs the
old one.
The only solutions to this at present are
- for the 2.x series to have a different package name, including 'v2'
- to force the user to play with class loaders, so they can load two
different versions of the same class
In summary, I suggest we all just let this one be. This isn't causing
major pain IMO. The lesson should be to not have dependencies between
commons projects wherever possible.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
