commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [IO] 2.0 RC2 available for review
Date Wed, 06 Oct 2010 16:48:58 GMT
Let's say IO went out as 2.0 and it was binary compatible. There are
enhancements planned for for 2.x that would break compatibility. Is
that still okay? I find it odd we would strive for 2.0 to be binary
compatible, but allow 2.x not to be.

Paul

On Wed, Oct 6, 2010 at 11:34 AM, Jörg Schaible <joerg.schaible@gmx.de> wrote:
> Hi guys,
>
> Niall Pemberton wrote:
>
>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <james@carmanconsulting.com>
>> wrote:
>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>> <niall.pemberton@gmail.com> wrote:
>>>>
>>>> There are four people who think 2.0 (Stephen and myself in this thread
>>>> and Sebb and Dennis in the previous thread back in March[1]) that
>>>> think it should be 2.0. So far there are five who think 1.5 (Jörg,
>>>> James, Michael, Paul & Matt). So people disagree. Its OK to have a
>>>> massive debate on this, but I would much rather spend my time on
>>>> something less trivial than version number ideology.
>>>>
>>>
>>> The problem is that you're causing some inconsistency.  Bumping major
>>> version numbers without changing package name/artifactId doesn't go
>>> along with what Apache Commons has come up with as a "best practice"
>>> or sorts.  Jumping to 2.0 also carries with it an assumption of binary
>>> incompatibility for most users.
>>
>> Commons is a federation. IMO Its not a one-size-fits all with a set of
>> rules to make all components adhere to. We do different things on
>> different projects and generally leave decisions up to the developers
>> on that component.
>>
>> I disagree completely with your assertions about version numbers:
>>
>> * We have some very widely used components that we don't break binary
>> compatibilty without a package name change (e.g. Lang, Logging,
>> Collections, IO, DBCP, BeanUtils to name some). However there are
>> other components where I think its OK to do that (for example
>> Validator 1.2.0 did removing deprecated items)
>>     http://markmail.org/message/omy4kiacas53pvfx
>
> We have the versioning guidelines
> (http://commons.apache.org/releases/versioning.html#Release_Types) and it is
> - as Sebastian stated - completely valid to increase the major version if
> substantially improvements have been made. Due to the compatible nature of
> this release it felt simply strange to me and I wanted to start the
> discussion before a vote is started.
>
>> * I agree with the practice that *if* a component decides to change
>> the package name, it should be a *major* version. But that is
>> different from a "a major version number therefore means a package
>> rename" and that is a something I've don't remember anyone even
>> suggesting here.
>>
>> I also don't agree with your assertion "assumption of binary
>> incompatibility for most users" - the vast majority of users never
>> even visit us here and are unaware of our practices. I bet that most
>> users either try-it-out before committing to and upgrade and if
>> they're concerned, go look for the release notes - which are very
>> clear on this.
>
> However, if we do not get a consensus on this topic, Niall is free as
> release manager to continue, because he's nevertheless in line with the
> versioning guidelines. Everyone, who disagrees including myself can take the
> role for the next release (of any component).
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message