commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [IO] 2.0 RC2 available for review
Date Wed, 06 Oct 2010 16:54:12 GMT
On Wed, Oct 6, 2010 at 5:48 PM, Paul Benedict <pbenedict@apache.org> wrote:
> 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?

No - if/when IO breaks binary compatibility, then IMO there will be a
package name change and major version. I'll sort out JIRA if/when this
release is out

Niall

> 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
>
>

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


Mime
View raw message