On 19.05.2007, at 21:37, Stephen Colebourne wrote:
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.
Sticking to the broken takes compatibility to another level. Whether
that is what the users demand - I doubt it.
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.
What are major version number releases for then in your opinion?
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
Have self contained jars and the problem (more or less) vanishes
because A comes with just the code it needs from the old beanutils
jar and B comes the new beanutils code. Unfortunately this will only
work if the underlying dependency does not get exposed - like we have
in this case. So we still have to be careful. But it would give a
whole lot more freedom for changes and re-use IMO.
In summary, I suggest we all just let this one be. This isn't
causing major pain IMO.
It feels a bit weird though. We are quite fussy about our releases
and now this is meant to be "naaa ...let it be!"?
How much pain was the broken cli jar causing that somehow got onto
the maven repos?
Also I don't know why have to keep the "just drop it in" attitude up
as such a high virtue.
The lesson should be to not have dependencies between commons
projects wherever possible.
I still don't buy into the "no dependencies" approach. There is a
difference between compile time and runtime. I do agree that self
contained projects are easier to handle - but that is also possible
with tools (as said before). Did I say that I hate duplicate
code? ...that's why I am here at Commons.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
