commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
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 <> 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


> 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 <> wrote:
>> Hi guys,
>> Niall Pemberton wrote:
>>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <>
>>> wrote:
>>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>>> <> 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
>>>>> 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)
>> We have the versioning guidelines
>> ( 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message