Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: <31cc37360802052002m20e99365l2b4114cc559cf82a@mail.gmail.com>
References: <170098.70022.qm@web86508.mail.ird.yahoo.com>
 <31cc37360802052002m20e99365l2b4114cc559cf82a@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DE519472-5A7C-4666-B969-2D1C9ECC0B3B@apache.org>
Content-Transfer-Encoding: 7bit
From: Torsten Curdt <tcurdt@apache.org>
Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
Date: Wed, 6 Feb 2008 12:02:22 +0100
To: "Jakarta Commons Developers List" <dev@commons.apache.org>

>> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org