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.
??? ...I think Stephen was just making a point about jar hell ...no?
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.
True ...it does bring up the question about deprecations - for minor
upgrades.
1.x -> 1.(x+1) ...will we ever *remove* deprecations? I think it is
common sense to remove them after a couple of releases.
Only 1.x.y -> 1.x.(y+1) should be stay as compatible that you can
drop them in without really reading the release notes.
For 1.x -> 1.(x+1) we should have the freedom to remove deprecations
after a couple of releases. This just needs to be well documented.
With pointers how to replace the deprecated method/class with the new
API.
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.
If someone thinks he can upgrade from 1.x to 2.x without changing
anything he deserves the pain to make sure he is still alive and
thinking ;)
While I think it's very important to be concerned of backwards
compatibility there is nothing wrong with a 2.x version to get out of
the paralyzes and move forward. That's life! If people don't want to
move forward they need to stick with what they have.
As long as we publish our release compatibility rules and stick to
them ...everyone will be OK I assume.
My 2 cents
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
