On Feb 5, 2008 5:27 AM, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> On 05.02.2008, at 06:44, Henri Yandell wrote: > > For Collections it makes sense as there's a big API change planned. > > For the others, I think they should charge in and see what kind of > API > > changes are required. If we're talking small ones, then I'd prefer > not > > to. I continue to not think that the next major version of a jar has > > to kill itself over backwards compatibility (ie: what's the point of > a > > major version). > > Because it is absolutely essential that we allow compatibility with the older > release. > > Specifically, it is a requirement that if there are any binary or source > incompatible changes, then an application must be able to run with both the > old and new jar files (v1.4 and v2.0). The only practical way in Java today > is to have the two incompatible versions in two separate packages. > > The practical impact of a new package is small to users that use commons-io > directly - a quick organize imports in an IDE. The impact of NOT doing this > would be jar hell, if your application relied on another open source library > that still used v1.4. Then there should never be a 2.0; it should remain as 1.5, 1.6, 1.12 etc. 2.0 is semantically meaningless. I buy your argument for huge changes, ie) collections-generics is very much a different product. I don't buy it for small API changes and removal of deprecation. Your argument would imply that we should never deprecate (as we're never going to actually remove it) and that we never increase a major version except for PR reasons. If IO 2.0 is hugely different so as to be a new product, then sure. If it's practically the same with minor API breakage, then I still don't see the need to cause pain to many for the few who think they can magically upgrade major versions in production. Sure we'll get cross-dependency problems, but that just implies to me that we shouldn't be doing major upgrades all the time. My tuppence anyway. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
