That's a reasonable style of versioning :) 

I had many issues with binary compatibilty with a commons-email release due to 
changing the return value from void to a this reference plus some moving of 
constants. You basically end up with either many restrictions or creating major 
releases

Cheers,

Siegfried Goeschl

> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tcu...@vafer.org>:
> 
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
> 
> My style of thinking: x.y.z
> 
> x - no compatibility
> y - source compatibility
> z - binary compatibility
> 
> is simple and makes sense.
> 
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not agree.
> 
> cheers,
> Torsten
> 
> 
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bode...@apache.org> wrote:
>> 
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>> 
>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>> 
>>>> - loosen API compatibility policy?
>> 
>>> This topic alone deserves its own thread I think.
>> 
>>> Ensuring binary/source compatibility is very important.
>> 
>> +1
>> 
>> I guess I've done too much ruby with "every bundle update runs the risk
>> of breaking everything" lately.  I really value the stability commons
>> provides.
>> 
>> That being said, I'm sure there are cases where our policy seems
>> stricter than it needs to be - even though I haven't seen a really
>> difficult case in the one component I contribute to.
>> 
>> Stefan
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to