You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2010/10/06 06:49:07 UTC

[IO] 2.0 RC2 available for review

I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
tag). As there have been quite a few changes in the last week, I'll
leave it a few days before even considering whether to call a vote, to
give time for feedback.

The distro is here:
    http://people.apache.org/~niallp/io-2.0-rc2/

Release Notes:
    http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt

Site:
    http://people.apache.org/~niallp/io-2.0-rc2/site/

Maven Stuff:
    http://people.apache.org/~niallp/io-2.0-rc2/maven/

Some Notes:

* There is one error on the clirr report - which is a false positive
(a generic method that is erased)
    http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
* Links to the JavaDoc versions on the site don't work (they will when
its deployed to the right location)

Thanks

Niall

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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Oct 8, 2010 at 3:06 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 12:21 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Thu, Oct 7, 2010 at 10:31 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>> Hi Niall,
>>>
>>> Niall Pemberton wrote:
>>>
>>>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>>>> tag). As there have been quite a few changes in the last week, I'll
>>>> leave it a few days before even considering whether to call a vote, to
>>>> give time for feedback.
>>>>
>>>> The distro is here:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>>>
>>>> Release Notes:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>>>
>>>> Site:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>>>
>>>> Maven Stuff:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>>>
>>>> Some Notes:
>>>>
>>>> * There is one error on the clirr report - which is a false positive
>>>> (a generic method that is erased)
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>>>> * Links to the JavaDoc versions on the site don't work (they will when
>>>> its deployed to the right location)
>>>
>>> Do you know why Gump is failing for "commons-io-test" since some weeks?
>>
>> There has been more than one reason for the failures :(
>>
>> Some times it was the FileSystemMonitorTestCase - which was also
>> failing in Continuum about every 3rd or 4th build. I made some changes
>> to that test and since then out of 43 builds it has only failed once.
>>
>> The other main cause is FileCleaningTrackerTestCase throwing an
>> OutOfMemoryError. This was failing in Continuum and I made some
>> changes which seemed to have reduced the failures but there is still
>> the odd instance of it. Gump seems to be failing mostly because of
>> this now (although it is passing some of the time). This test tries to
>> fill up memory so that PhantomReferences get released - so thats
>> causing the OutOfMemoryError and is a problem with the test rather
>> than FileCleaningTracker
>>
>> I have updated the following JIRA ticket with the history of Continuum
>> builds and the causes of the failures:
>>    https://issues.apache.org/jira/browse/IO-196
>>
>> In summary though most failures are FileCleaningTrackerTestCase and
>> the problem is the test case.
>
> I've done some additional work on both the FileSystemMonitorTestCase
> and FileCleaningTrackerTestCase which I hope will get rid of the
> errors. Gump has been pretty much daily, so should have an indication
> soon. I have added the gump failures to the JIRA issue (from the mail
> archive) - can't tell the cause as theres no history AFAIK with gump.
>    https://issues.apache.org/jira/browse/IO-196

Continuum has now run 30 builds without failing. Since the failures
are intermittent, theres no guarantee that they won't fail again, but
I believe that with the changes I've made they will at least happen
much less. I put together the following page which shows the history
of Continuum builds, which test caused each failure and the related
changes I've made:

   http://people.apache.org/~niallp/io-2.0/IOFailures.html

>From seeing Continuum failure emails, it may seem that it has been
failing alot - but I think that the above shows that this is now not
the case for the individual tests.

Niall


> Because of these changes I'm going to roll another RC
>
>> Niall
>>
>>> - Jörg
>>
>

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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Oct 7, 2010 at 12:21 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 10:31 AM, Jörg Schaible <jo...@gmx.de> wrote:
>> Hi Niall,
>>
>> Niall Pemberton wrote:
>>
>>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>>> tag). As there have been quite a few changes in the last week, I'll
>>> leave it a few days before even considering whether to call a vote, to
>>> give time for feedback.
>>>
>>> The distro is here:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>>
>>> Release Notes:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>>
>>> Site:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>>
>>> Maven Stuff:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>>
>>> Some Notes:
>>>
>>> * There is one error on the clirr report - which is a false positive
>>> (a generic method that is erased)
>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>>> * Links to the JavaDoc versions on the site don't work (they will when
>>> its deployed to the right location)
>>
>> Do you know why Gump is failing for "commons-io-test" since some weeks?
>
> There has been more than one reason for the failures :(
>
> Some times it was the FileSystemMonitorTestCase - which was also
> failing in Continuum about every 3rd or 4th build. I made some changes
> to that test and since then out of 43 builds it has only failed once.
>
> The other main cause is FileCleaningTrackerTestCase throwing an
> OutOfMemoryError. This was failing in Continuum and I made some
> changes which seemed to have reduced the failures but there is still
> the odd instance of it. Gump seems to be failing mostly because of
> this now (although it is passing some of the time). This test tries to
> fill up memory so that PhantomReferences get released - so thats
> causing the OutOfMemoryError and is a problem with the test rather
> than FileCleaningTracker
>
> I have updated the following JIRA ticket with the history of Continuum
> builds and the causes of the failures:
>    https://issues.apache.org/jira/browse/IO-196
>
> In summary though most failures are FileCleaningTrackerTestCase and
> the problem is the test case.

I've done some additional work on both the FileSystemMonitorTestCase
and FileCleaningTrackerTestCase which I hope will get rid of the
errors. Gump has been pretty much daily, so should have an indication
soon. I have added the gump failures to the JIRA issue (from the mail
archive) - can't tell the cause as theres no history AFAIK with gump.
    https://issues.apache.org/jira/browse/IO-196

Because of these changes I'm going to roll another RC

> Niall
>
>> - Jörg
>

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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Oct 7, 2010 at 10:31 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Hi Niall,
>
> Niall Pemberton wrote:
>
>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>> tag). As there have been quite a few changes in the last week, I'll
>> leave it a few days before even considering whether to call a vote, to
>> give time for feedback.
>>
>> The distro is here:
>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>
>> Release Notes:
>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>
>> Site:
>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>
>> Maven Stuff:
>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>
>> Some Notes:
>>
>> * There is one error on the clirr report - which is a false positive
>> (a generic method that is erased)
>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>> * Links to the JavaDoc versions on the site don't work (they will when
>> its deployed to the right location)
>
> Do you know why Gump is failing for "commons-io-test" since some weeks?

There has been more than one reason for the failures :(

Some times it was the FileSystemMonitorTestCase - which was also
failing in Continuum about every 3rd or 4th build. I made some changes
to that test and since then out of 43 builds it has only failed once.

The other main cause is FileCleaningTrackerTestCase throwing an
OutOfMemoryError. This was failing in Continuum and I made some
changes which seemed to have reduced the failures but there is still
the odd instance of it. Gump seems to be failing mostly because of
this now (although it is passing some of the time). This test tries to
fill up memory so that PhantomReferences get released - so thats
causing the OutOfMemoryError and is a problem with the test rather
than FileCleaningTracker

I have updated the following JIRA ticket with the history of Continuum
builds and the causes of the failures:
    https://issues.apache.org/jira/browse/IO-196

In summary though most failures are FileCleaningTrackerTestCase and
the problem is the test case.

Niall

> - Jörg

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


Re: [IO] 2.0 RC2 available for review

Posted by Jörg Schaible <jo...@gmx.de>.
Hi Niall,

Niall Pemberton wrote:

> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
> tag). As there have been quite a few changes in the last week, I'll
> leave it a few days before even considering whether to call a vote, to
> give time for feedback.
> 
> The distro is here:
>     http://people.apache.org/~niallp/io-2.0-rc2/
> 
> Release Notes:
>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
> 
> Site:
>     http://people.apache.org/~niallp/io-2.0-rc2/site/
> 
> Maven Stuff:
>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
> 
> Some Notes:
> 
> * There is one error on the clirr report - which is a false positive
> (a generic method that is erased)
>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
> * Links to the JavaDoc versions on the site don't work (they will when
> its deployed to the right location)

Do you know why Gump is failing for "commons-io-test" since some weeks?

- Jörg


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


Re: [IO] 2.0 RC2 available for review

Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Oct 6, 2010 at 12:08 PM, Niall Pemberton
<ni...@gmail.com> wrote:
>
> 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.
>

If this is the case, then the rest of your argument is moot.  It
doesn't matter what I think.

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


Re: [IO] 2.0 RC2 available for review

Posted by Gary Gregory <GG...@seagullsoftware.com>.
On Oct 6, 2010, at 9:35, "Jörg Schaible" <jo...@gmx.de> wrote:

> Hi guys,
> 
> Niall Pemberton wrote:
> 
>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <ja...@carmanconsulting.com>
>> wrote:
>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>> <ni...@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
> 
If our rules/guidelines allow the RM to decide, let's let him decide. If the decision is within the version guidelines, why wouldn't we be done?

I guess we like to kibitz :)

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


Re: [IO] 2.0 RC2 available for review

Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Oct 6, 2010 at 12:54 PM, Niall Pemberton
<ni...@gmail.com> wrote:
>
> 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
>

So, we have:

Version 1.x: org.apache.commons.io

Version 2.x: org.apache.commons.io

Version 3.x: org.apache.commons.io3

It's inconsistent, but then again it really doesn't matter what I think.

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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Oct 6, 2010 at 5:48 PM, Paul Benedict <pb...@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 <jo...@gmx.de> wrote:
>> Hi guys,
>>
>> Niall Pemberton wrote:
>>
>>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <ja...@carmanconsulting.com>
>>> wrote:
>>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>>> <ni...@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


Re: [IO] 2.0 RC2 available for review

Posted by Paul Benedict <pb...@apache.org>.
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 <jo...@gmx.de> wrote:
> Hi guys,
>
> Niall Pemberton wrote:
>
>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <ja...@carmanconsulting.com>
>> wrote:
>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>> <ni...@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


Re: [IO] 2.0 RC2 available for review

Posted by Jörg Schaible <jo...@gmx.de>.
Hi guys,

Niall Pemberton wrote:

> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>> <ni...@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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Oct 6, 2010 at 4:20 PM, James Carman <ja...@carmanconsulting.com> wrote:
> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
> <ni...@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

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

Niall

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


Re: [IO] 2.0 RC2 available for review

Posted by sebb <se...@gmail.com>.
On 6 October 2010 16:20, James Carman <ja...@carmanconsulting.com> wrote:
> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
> <ni...@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.

Not necessarily. A major version change might be justified if the code
was significantly updated, e.g. to add major new functionality.

However, I agree that changing package name or Maven G:A does require
a major version change.

BTW, the reason that I think changing the minimum JVM warrants a major
version change is that the code is no longer a drop-in replacement for
users who are on the minimum Java version. But this probably depends
on the user base for that Java version. If IO had been changed to
require Java 6 when it first came out, I suspect that most of you
would have insisted on a major version change.

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


Re: [IO] 2.0 RC2 available for review

Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
<ni...@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.

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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Oct 6, 2010 at 3:36 PM, Matt Benson <gu...@gmail.com> wrote:
>
> On Oct 6, 2010, at 9:32 AM, Michael Wooten wrote:
>
>> Hey All,
>>
>> As a user (and occasional contributor) I would have to agree with Jorg
>> that 1.5 makes more sense, in the fact that it does retain binary
>> compatibility. Like with Lang 3.0, I would expect that the 2.0 release
>> would be a major change (dropping backwards compatibility, removing
>> deprecated code, using incompatible 1.5 features, etc.). The new
>> refinements sound more like an extension to the 1.4 release to me, so
>> 1.5 makes more sense.
>>
>> Will there be a point in the future where IO will be removing
>> deprecated code and dropping backwards compatibility? If so, what
>> release of IO will that be? That sounds more like a 2.0 release to me,
>> but that's my opinion.
>>
>
> I'm personally leaning toward 1.5 as well.  The bugfix along the 1.3 compatible line point is a red herring as the hypothetical fixes would be made against 1.4.x.

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.

[1] http://markmail.org/message/flsmdalzs6tjv3va

> $0.02,
> Matt
>
>> -Michael
>>
>> On Wed, Oct 6, 2010 at 8:49 AM, Niall Pemberton
>> <ni...@gmail.com> wrote:
>>> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>
>>>>> Nial wrote:
>>>>>> The original plan for 2.0 was thinking it would be *incompatible* and
>>>>>> hence the major version changed - I guess it mainly stuck from that
>>>>>> starting point:
>>>>>>
>>>>>> http://markmail.org/message/46dos5wjdfhcr5nr
>>>>>>
>>>>>> Sebb did bring this up earlier this year though - although most of
>>>>>> that debate ended up about maven groupIds:
>>>>>>
>>>>>> http://markmail.org/message/flsmdalzs6tjv3va
>>>>>>
>>>>>> It is arbitrary though - my preference is for 2.0 since it makes it
>>>>>> easy to remember which releases were for JDK 1.3 and which for JDK
>>>>>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>>>>>> change than +0.1
>>>>
>>>>
>>>> James Carman wrote:
>>>>> So, call it 1.5
>>>>
>>>> Hehehe.
>>>>
>>>> Seriously, we have switched the minimal JDK requirement often between minor
>>>> versions (most prominent case is DBCP) and kept Maven G:A as long as it is
>>>> binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks
>>>> strange to me switching for io from 1.x to 2.0.
>>>
>>> I guess it is a bit arbitrary - but then I think each component makes
>>> the decision on a case-by-case basis. It doesn't seem strange to me
>>> and I prefer 2.0 than 1.5. Also it leaves room if we ever want to
>>> release a bug-fix for the JDK 1.3 branch. I know thats unlikely,
>>> although Jukka did talk of doing this for Jackrabbit
>>>
>>>    http://markmail.org/message/ijeuxvemzmdzuw3s
>>>
>>>> What would be your intention as a normal user with this versioning?
>>>> Would you use it as drop in replacement?
>>>
>>> Its drop in except you now need a later JDK version. Anyway, I would
>>> hope they would read the release notes:
>>>
>>>   http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html
>>>
>>> ...and be pleasantly surprised that it is a drop in replacement :)
>>>
>>> I do think it from a user PoV it does make it easier to remember which
>>> version the JDK change happened and I think it likely users would find
>>> it strange that a change in JDK version only warranted a +0.1 in
>>> version number.
>>>
>>> Niall
>>>
>>>> - Jörg
>>>

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


Re: [IO] 2.0 RC2 available for review

Posted by Matt Benson <gu...@gmail.com>.
On Oct 6, 2010, at 9:32 AM, Michael Wooten wrote:

> Hey All,
> 
> As a user (and occasional contributor) I would have to agree with Jorg
> that 1.5 makes more sense, in the fact that it does retain binary
> compatibility. Like with Lang 3.0, I would expect that the 2.0 release
> would be a major change (dropping backwards compatibility, removing
> deprecated code, using incompatible 1.5 features, etc.). The new
> refinements sound more like an extension to the 1.4 release to me, so
> 1.5 makes more sense.
> 
> Will there be a point in the future where IO will be removing
> deprecated code and dropping backwards compatibility? If so, what
> release of IO will that be? That sounds more like a 2.0 release to me,
> but that's my opinion.
> 

I'm personally leaning toward 1.5 as well.  The bugfix along the 1.3 compatible line point is a red herring as the hypothetical fixes would be made against 1.4.x.

$0.02,
Matt

> -Michael
> 
> On Wed, Oct 6, 2010 at 8:49 AM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>> 
>>>> Nial wrote:
>>>>> The original plan for 2.0 was thinking it would be *incompatible* and
>>>>> hence the major version changed - I guess it mainly stuck from that
>>>>> starting point:
>>>>> 
>>>>> http://markmail.org/message/46dos5wjdfhcr5nr
>>>>> 
>>>>> Sebb did bring this up earlier this year though - although most of
>>>>> that debate ended up about maven groupIds:
>>>>> 
>>>>> http://markmail.org/message/flsmdalzs6tjv3va
>>>>> 
>>>>> It is arbitrary though - my preference is for 2.0 since it makes it
>>>>> easy to remember which releases were for JDK 1.3 and which for JDK
>>>>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>>>>> change than +0.1
>>> 
>>> 
>>> James Carman wrote:
>>>> So, call it 1.5
>>> 
>>> Hehehe.
>>> 
>>> Seriously, we have switched the minimal JDK requirement often between minor
>>> versions (most prominent case is DBCP) and kept Maven G:A as long as it is
>>> binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks
>>> strange to me switching for io from 1.x to 2.0.
>> 
>> I guess it is a bit arbitrary - but then I think each component makes
>> the decision on a case-by-case basis. It doesn't seem strange to me
>> and I prefer 2.0 than 1.5. Also it leaves room if we ever want to
>> release a bug-fix for the JDK 1.3 branch. I know thats unlikely,
>> although Jukka did talk of doing this for Jackrabbit
>> 
>>    http://markmail.org/message/ijeuxvemzmdzuw3s
>> 
>>> What would be your intention as a normal user with this versioning?
>>> Would you use it as drop in replacement?
>> 
>> Its drop in except you now need a later JDK version. Anyway, I would
>> hope they would read the release notes:
>> 
>>   http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html
>> 
>> ...and be pleasantly surprised that it is a drop in replacement :)
>> 
>> I do think it from a user PoV it does make it easier to remember which
>> version the JDK change happened and I think it likely users would find
>> it strange that a change in JDK version only warranted a +0.1 in
>> version number.
>> 
>> Niall
>> 
>>> - 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


Re: [IO] 2.0 RC2 available for review

Posted by Paul Benedict <pb...@apache.org>.
I tend to agree that 2.0 should allow backwards incompatible changes.
If it is simply adding generics and cleaning up code, it deserves a
1.5 version number. That's how I see it anyway.

Paul

On Wed, Oct 6, 2010 at 9:32 AM, Michael Wooten <mw...@gmail.com> wrote:
> Hey All,
>
> As a user (and occasional contributor) I would have to agree with Jorg
> that 1.5 makes more sense, in the fact that it does retain binary
> compatibility. Like with Lang 3.0, I would expect that the 2.0 release
> would be a major change (dropping backwards compatibility, removing
> deprecated code, using incompatible 1.5 features, etc.). The new
> refinements sound more like an extension to the 1.4 release to me, so
> 1.5 makes more sense.
>
> Will there be a point in the future where IO will be removing
> deprecated code and dropping backwards compatibility? If so, what
> release of IO will that be? That sounds more like a 2.0 release to me,
> but that's my opinion.
>
> -Michael
>
> On Wed, Oct 6, 2010 at 8:49 AM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>>
>>>> Nial wrote:
>>>>> The original plan for 2.0 was thinking it would be *incompatible* and
>>>>> hence the major version changed - I guess it mainly stuck from that
>>>>> starting point:
>>>>>
>>>>> http://markmail.org/message/46dos5wjdfhcr5nr
>>>>>
>>>>> Sebb did bring this up earlier this year though - although most of
>>>>> that debate ended up about maven groupIds:
>>>>>
>>>>> http://markmail.org/message/flsmdalzs6tjv3va
>>>>>
>>>>> It is arbitrary though - my preference is for 2.0 since it makes it
>>>>> easy to remember which releases were for JDK 1.3 and which for JDK
>>>>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>>>>> change than +0.1
>>>
>>>
>>> James Carman wrote:
>>>> So, call it 1.5
>>>
>>> Hehehe.
>>>
>>> Seriously, we have switched the minimal JDK requirement often between minor
>>> versions (most prominent case is DBCP) and kept Maven G:A as long as it is
>>> binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks
>>> strange to me switching for io from 1.x to 2.0.
>>
>> I guess it is a bit arbitrary - but then I think each component makes
>> the decision on a case-by-case basis. It doesn't seem strange to me
>> and I prefer 2.0 than 1.5. Also it leaves room if we ever want to
>> release a bug-fix for the JDK 1.3 branch. I know thats unlikely,
>> although Jukka did talk of doing this for Jackrabbit
>>
>>    http://markmail.org/message/ijeuxvemzmdzuw3s
>>
>>> What would be your intention as a normal user with this versioning?
>>> Would you use it as drop in replacement?
>>
>> Its drop in except you now need a later JDK version. Anyway, I would
>> hope they would read the release notes:
>>
>>   http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html
>>
>> ...and be pleasantly surprised that it is a drop in replacement :)
>>
>> I do think it from a user PoV it does make it easier to remember which
>> version the JDK change happened and I think it likely users would find
>> it strange that a change in JDK version only warranted a +0.1 in
>> version number.
>>
>> Niall
>>
>>> - 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


Re: [IO] 2.0 RC2 available for review

Posted by Michael Wooten <mw...@gmail.com>.
Hey All,

As a user (and occasional contributor) I would have to agree with Jorg
that 1.5 makes more sense, in the fact that it does retain binary
compatibility. Like with Lang 3.0, I would expect that the 2.0 release
would be a major change (dropping backwards compatibility, removing
deprecated code, using incompatible 1.5 features, etc.). The new
refinements sound more like an extension to the 1.4 release to me, so
1.5 makes more sense.

Will there be a point in the future where IO will be removing
deprecated code and dropping backwards compatibility? If so, what
release of IO will that be? That sounds more like a 2.0 release to me,
but that's my opinion.

-Michael

On Wed, Oct 6, 2010 at 8:49 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>
>>> Nial wrote:
>>>> The original plan for 2.0 was thinking it would be *incompatible* and
>>>> hence the major version changed - I guess it mainly stuck from that
>>>> starting point:
>>>>
>>>> http://markmail.org/message/46dos5wjdfhcr5nr
>>>>
>>>> Sebb did bring this up earlier this year though - although most of
>>>> that debate ended up about maven groupIds:
>>>>
>>>> http://markmail.org/message/flsmdalzs6tjv3va
>>>>
>>>> It is arbitrary though - my preference is for 2.0 since it makes it
>>>> easy to remember which releases were for JDK 1.3 and which for JDK
>>>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>>>> change than +0.1
>>
>>
>> James Carman wrote:
>>> So, call it 1.5
>>
>> Hehehe.
>>
>> Seriously, we have switched the minimal JDK requirement often between minor
>> versions (most prominent case is DBCP) and kept Maven G:A as long as it is
>> binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks
>> strange to me switching for io from 1.x to 2.0.
>
> I guess it is a bit arbitrary - but then I think each component makes
> the decision on a case-by-case basis. It doesn't seem strange to me
> and I prefer 2.0 than 1.5. Also it leaves room if we ever want to
> release a bug-fix for the JDK 1.3 branch. I know thats unlikely,
> although Jukka did talk of doing this for Jackrabbit
>
>    http://markmail.org/message/ijeuxvemzmdzuw3s
>
>> What would be your intention as a normal user with this versioning?
>> Would you use it as drop in replacement?
>
> Its drop in except you now need a later JDK version. Anyway, I would
> hope they would read the release notes:
>
>   http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html
>
> ...and be pleasantly surprised that it is a drop in replacement :)
>
> I do think it from a user PoV it does make it easier to remember which
> version the JDK change happened and I think it likely users would find
> it strange that a change in JDK version only warranted a +0.1 in
> version number.
>
> Niall
>
>> - 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


Re: [IO] 2.0 RC2 available for review

Posted by Gary Gregory <GG...@seagullsoftware.com>.
On Oct 6, 2010, at 5:49, "Niall Pemberton" <ni...@gmail.com>> wrote:

On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <jo...@gmx.de>> wrote:

Nial wrote:
The original plan for 2.0 was thinking it would be *incompatible* and
hence the major version changed - I guess it mainly stuck from that
starting point:

http://markmail.org/message/46dos5wjdfhcr5nr

Sebb did bring this up earlier this year though - although most of
that debate ended up about maven groupIds:

http://markmail.org/message/flsmdalzs6tjv3va

It is arbitrary though - my preference is for 2.0 since it makes it
easy to remember which releases were for JDK 1.3 and which for JDK
1.5. Also it seems like moving to JDK 1.5 warrants more of a version
change than +0.1


James Carman wrote:
So, call it 1.5

Hehehe.

Seriously, we have switched the minimal JDK requirement often between minor
versions (most prominent case is DBCP) and kept Maven G:A as long as it is
binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks
strange to me switching for io from 1.x to 2.0.

I guess it is a bit arbitrary - but then I think each component makes
the decision on a case-by-case basis. It doesn't seem strange to me
and I prefer 2.0 than 1.5. Also it leaves room if we ever want to
release a bug-fix for the JDK 1.3 branch. I know thats unlikely,
although Jukka did talk of doing this for Jackrabbit

A bug fix release would be a 1.4.x release though...
   <http://markmail.org/message/ijeuxvemzmdzuw3s> http://markmail.org/message/ijeuxvemzmdzuw3s

What would be your intention as a normal user with this versioning?
Would you use it as drop in replacement?

Its drop in except you now need a later JDK version. Anyway, I would
hope they would read the release notes:

  <http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html> http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html

...and be pleasantly surprised that it is a drop in replacement :)

I do think it from a user PoV it does make it easier to remember which
version the JDK change happened and I think it likely users would find
it strange that a change in JDK version only warranted a +0.1 in
version number.

Niall

- Jörg

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


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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <jo...@gmx.de> wrote:
>
>> Nial wrote:
>>> The original plan for 2.0 was thinking it would be *incompatible* and
>>> hence the major version changed - I guess it mainly stuck from that
>>> starting point:
>>>
>>> http://markmail.org/message/46dos5wjdfhcr5nr
>>>
>>> Sebb did bring this up earlier this year though - although most of
>>> that debate ended up about maven groupIds:
>>>
>>> http://markmail.org/message/flsmdalzs6tjv3va
>>>
>>> It is arbitrary though - my preference is for 2.0 since it makes it
>>> easy to remember which releases were for JDK 1.3 and which for JDK
>>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>>> change than +0.1
>
>
> James Carman wrote:
>> So, call it 1.5
>
> Hehehe.
>
> Seriously, we have switched the minimal JDK requirement often between minor
> versions (most prominent case is DBCP) and kept Maven G:A as long as it is
> binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks
> strange to me switching for io from 1.x to 2.0.

I guess it is a bit arbitrary - but then I think each component makes
the decision on a case-by-case basis. It doesn't seem strange to me
and I prefer 2.0 than 1.5. Also it leaves room if we ever want to
release a bug-fix for the JDK 1.3 branch. I know thats unlikely,
although Jukka did talk of doing this for Jackrabbit

    http://markmail.org/message/ijeuxvemzmdzuw3s

> What would be your intention as a normal user with this versioning?
> Would you use it as drop in replacement?

Its drop in except you now need a later JDK version. Anyway, I would
hope they would read the release notes:

   http://people.apache.org/~niallp/io-2.0-rc2/site/upgradeto2_0.html

...and be pleasantly surprised that it is a drop in replacement :)

I do think it from a user PoV it does make it easier to remember which
version the JDK change happened and I think it likely users would find
it strange that a change in JDK version only warranted a +0.1 in
version number.

Niall

> - Jörg

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


Re: [IO] 2.0 RC2 available for review

Posted by Jörg Schaible <jo...@gmx.de>.
> Nial wrote:
>> The original plan for 2.0 was thinking it would be *incompatible* and
>> hence the major version changed - I guess it mainly stuck from that
>> starting point:
>>
>> http://markmail.org/message/46dos5wjdfhcr5nr
>>
>> Sebb did bring this up earlier this year though - although most of
>> that debate ended up about maven groupIds:
>>
>> http://markmail.org/message/flsmdalzs6tjv3va
>>
>> It is arbitrary though - my preference is for 2.0 since it makes it
>> easy to remember which releases were for JDK 1.3 and which for JDK
>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>> change than +0.1


James Carman wrote:
> So, call it 1.5

Hehehe.

Seriously, we have switched the minimal JDK requirement often between minor 
versions (most prominent case is DBCP) and kept Maven G:A as long as it is 
binary compatible. Comparing the gap from lang 2.x to lang 3.x, it looks 
strange to me switching for io from 1.x to 2.0. What would be your intention 
as a normal user with this versioning? Would you use it as drop in 
replacement?

- Jörg


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


Re: [IO] 2.0 RC2 available for review

Posted by James Carman <ja...@carmanconsulting.com>.
So, call it 1.5

On Wed, Oct 6, 2010 at 6:49 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <jo...@gmx.de> wrote:
>> Hi Niall,
>>
>> Niall Pemberton wrote:
>>
>>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>>> tag). As there have been quite a few changes in the last week, I'll
>>> leave it a few days before even considering whether to call a vote, to
>>> give time for feedback.
>>>
>>> The distro is here:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>>
>>> Release Notes:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>>
>>> Site:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>>
>>> Maven Stuff:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>>
>>> Some Notes:
>>>
>>> * There is one error on the clirr report - which is a false positive
>>> (a generic method that is erased)
>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>>> * Links to the JavaDoc versions on the site don't work (they will when
>>> its deployed to the right location)
>>
>> thanks for all the work you put into this release. I had not the time to
>> look at the new stuff in detail, but looking at the release notes, I wonder
>> about the version:
>>
>> 1/ requires now Java 5 instead of 1.3
>> 2/ is binary compatible with 1.4
>> 3/ does not remove deprecated stuff
>> 4/ is using the same package name
>> 5/ is using the old Maven groupId
>> 6/ adds a lot new stuff
>> 7/ deprecates some stuff
>> 8/ contains bug fixes
>>
>> IMHO we started with 2.0 because we were not sure if topic 2/ and 3/ can be
>> ensured for 1/ and it was not a primary goal. However, this turned out fine
>> and 1/ has been never forcing a major version change in general. So, is
>> there any other reason to call this release 2.0 instead of 1.5?
>
> The original plan for 2.0 was thinking it would be *incompatible* and
> hence the major version changed - I guess it mainly stuck from that
> starting point:
>
>    http://markmail.org/message/46dos5wjdfhcr5nr
>
> Sebb did bring this up earlier this year though - although most of
> that debate ended up about maven groupIds:
>
>    http://markmail.org/message/flsmdalzs6tjv3va
>
> It is arbitrary though - my preference is for 2.0 since it makes it
> easy to remember which releases were for JDK 1.3 and which for JDK
> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
> change than +0.1
>
> Niall
>
>> Cheers,
>> 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


Re: [IO] 2.0 RC2 available for review

Posted by Stephen Colebourne <sc...@joda.org>.
On 6 October 2010 11:49, Niall Pemberton <ni...@gmail.com> wrote:
> The original plan for 2.0 was thinking it would be *incompatible* and
> hence the major version changed - I guess it mainly stuck from that
> starting point:
>
>    http://markmail.org/message/46dos5wjdfhcr5nr
>
> Sebb did bring this up earlier this year though - although most of
> that debate ended up about maven groupIds:
>
>    http://markmail.org/message/flsmdalzs6tjv3va
>
> It is arbitrary though - my preference is for 2.0 since it makes it
> easy to remember which releases were for JDK 1.3 and which for JDK
> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
> change than +0.1

A move to JDK 1.5 would be sufficient for a v2.0 IMO.

Stephen

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


Re: [IO] 2.0 RC2 available for review

Posted by Paul Benedict <pb...@apache.org>.
Niall, if the rules allow a major version bump, then you are free to
do it. However, the major version bump is misleading to me and I
wouldn't choose it if I was RM.

On Wed, Oct 6, 2010 at 12:01 PM, Gary Gregory
<GG...@seagullsoftware.com> wrote:
> On Oct 6, 2010, at 3:50, "Niall Pemberton" <ni...@gmail.com> wrote:
>
>> On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>> Hi Niall,
>>>
>>> Niall Pemberton wrote:
>>>
>>>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>>>> tag). As there have been quite a few changes in the last week, I'll
>>>> leave it a few days before even considering whether to call a vote, to
>>>> give time for feedback.
>>>>
>>>> The distro is here:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>>>
>>>> Release Notes:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>>>
>>>> Site:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>>>
>>>> Maven Stuff:
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>>>
>>>> Some Notes:
>>>>
>>>> * There is one error on the clirr report - which is a false positive
>>>> (a generic method that is erased)
>>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>>>> * Links to the JavaDoc versions on the site don't work (they will when
>>>> its deployed to the right location)
>>>
>>> thanks for all the work you put into this release. I had not the time to
>>> look at the new stuff in detail, but looking at the release notes, I wonder
>>> about the version:
>>>
>>> 1/ requires now Java 5 instead of 1.3
>>> 2/ is binary compatible with 1.4
>>> 3/ does not remove deprecated stuff
>>> 4/ is using the same package name
>>> 5/ is using the old Maven groupId
>>> 6/ adds a lot new stuff
>>> 7/ deprecates some stuff
>>> 8/ contains bug fixes
>>>
>>> IMHO we started with 2.0 because we were not sure if topic 2/ and 3/ can be
>>> ensured for 1/ and it was not a primary goal. However, this turned out fine
>>> and 1/ has been never forcing a major version change in general. So, is
>>> there any other reason to call this release 2.0 instead of 1.5?
>>
>> The original plan for 2.0 was thinking it would be *incompatible* and
>> hence the major version changed - I guess it mainly stuck from that
>> starting point:
>>
>>    http://markmail.org/message/46dos5wjdfhcr5nr
>>
>> Sebb did bring this up earlier this year though - although most of
>> that debate ended up about maven groupIds:
>>
>>    http://markmail.org/message/flsmdalzs6tjv3va
>>
>> It is arbitrary though - my preference is for 2.0 since it makes it
>> easy to remember which releases were for JDK 1.3 and which for JDK
>> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
>> change than +0.1
>>
> +1, a major jre req change warrants a +1.0 to the version.
>
> Gary
>
>> Niall
>>
>>> Cheers,
>>> 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


Re: [IO] 2.0 RC2 available for review

Posted by Gary Gregory <GG...@seagullsoftware.com>.
On Oct 6, 2010, at 3:50, "Niall Pemberton" <ni...@gmail.com> wrote:

> On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <jo...@gmx.de> wrote:
>> Hi Niall,
>> 
>> Niall Pemberton wrote:
>> 
>>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>>> tag). As there have been quite a few changes in the last week, I'll
>>> leave it a few days before even considering whether to call a vote, to
>>> give time for feedback.
>>> 
>>> The distro is here:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>> 
>>> Release Notes:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>> 
>>> Site:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>> 
>>> Maven Stuff:
>>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>> 
>>> Some Notes:
>>> 
>>> * There is one error on the clirr report - which is a false positive
>>> (a generic method that is erased)
>>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>>> * Links to the JavaDoc versions on the site don't work (they will when
>>> its deployed to the right location)
>> 
>> thanks for all the work you put into this release. I had not the time to
>> look at the new stuff in detail, but looking at the release notes, I wonder
>> about the version:
>> 
>> 1/ requires now Java 5 instead of 1.3
>> 2/ is binary compatible with 1.4
>> 3/ does not remove deprecated stuff
>> 4/ is using the same package name
>> 5/ is using the old Maven groupId
>> 6/ adds a lot new stuff
>> 7/ deprecates some stuff
>> 8/ contains bug fixes
>> 
>> IMHO we started with 2.0 because we were not sure if topic 2/ and 3/ can be
>> ensured for 1/ and it was not a primary goal. However, this turned out fine
>> and 1/ has been never forcing a major version change in general. So, is
>> there any other reason to call this release 2.0 instead of 1.5?
> 
> The original plan for 2.0 was thinking it would be *incompatible* and
> hence the major version changed - I guess it mainly stuck from that
> starting point:
> 
>    http://markmail.org/message/46dos5wjdfhcr5nr
> 
> Sebb did bring this up earlier this year though - although most of
> that debate ended up about maven groupIds:
> 
>    http://markmail.org/message/flsmdalzs6tjv3va
> 
> It is arbitrary though - my preference is for 2.0 since it makes it
> easy to remember which releases were for JDK 1.3 and which for JDK
> 1.5. Also it seems like moving to JDK 1.5 warrants more of a version
> change than +0.1
> 
+1, a major jre req change warrants a +1.0 to the version.  

Gary

> Niall
> 
>> Cheers,
>> 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


Re: [IO] 2.0 RC2 available for review

Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Hi Niall,
>
> Niall Pemberton wrote:
>
>> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
>> tag). As there have been quite a few changes in the last week, I'll
>> leave it a few days before even considering whether to call a vote, to
>> give time for feedback.
>>
>> The distro is here:
>>     http://people.apache.org/~niallp/io-2.0-rc2/
>>
>> Release Notes:
>>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
>>
>> Site:
>>     http://people.apache.org/~niallp/io-2.0-rc2/site/
>>
>> Maven Stuff:
>>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
>>
>> Some Notes:
>>
>> * There is one error on the clirr report - which is a false positive
>> (a generic method that is erased)
>>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
>> * Links to the JavaDoc versions on the site don't work (they will when
>> its deployed to the right location)
>
> thanks for all the work you put into this release. I had not the time to
> look at the new stuff in detail, but looking at the release notes, I wonder
> about the version:
>
> 1/ requires now Java 5 instead of 1.3
> 2/ is binary compatible with 1.4
> 3/ does not remove deprecated stuff
> 4/ is using the same package name
> 5/ is using the old Maven groupId
> 6/ adds a lot new stuff
> 7/ deprecates some stuff
> 8/ contains bug fixes
>
> IMHO we started with 2.0 because we were not sure if topic 2/ and 3/ can be
> ensured for 1/ and it was not a primary goal. However, this turned out fine
> and 1/ has been never forcing a major version change in general. So, is
> there any other reason to call this release 2.0 instead of 1.5?

The original plan for 2.0 was thinking it would be *incompatible* and
hence the major version changed - I guess it mainly stuck from that
starting point:

    http://markmail.org/message/46dos5wjdfhcr5nr

Sebb did bring this up earlier this year though - although most of
that debate ended up about maven groupIds:

    http://markmail.org/message/flsmdalzs6tjv3va

It is arbitrary though - my preference is for 2.0 since it makes it
easy to remember which releases were for JDK 1.3 and which for JDK
1.5. Also it seems like moving to JDK 1.5 warrants more of a version
change than +0.1

Niall

> Cheers,
> Jörg

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


Re: [IO] 2.0 RC2 available for review

Posted by Jörg Schaible <jo...@gmx.de>.
Hi Niall,

Niall Pemberton wrote:

> I have prepared Commons IO 2.0 RC2 for review (rc1 never went past the
> tag). As there have been quite a few changes in the last week, I'll
> leave it a few days before even considering whether to call a vote, to
> give time for feedback.
> 
> The distro is here:
>     http://people.apache.org/~niallp/io-2.0-rc2/
> 
> Release Notes:
>     http://people.apache.org/~niallp/io-2.0-rc2/RELEASE-NOTES.txt
> 
> Site:
>     http://people.apache.org/~niallp/io-2.0-rc2/site/
> 
> Maven Stuff:
>     http://people.apache.org/~niallp/io-2.0-rc2/maven/
> 
> Some Notes:
> 
> * There is one error on the clirr report - which is a false positive
> (a generic method that is erased)
>     http://people.apache.org/~niallp/io-2.0-rc2/site/clirr-report.html
> * Links to the JavaDoc versions on the site don't work (they will when
> its deployed to the right location)

thanks for all the work you put into this release. I had not the time to 
look at the new stuff in detail, but looking at the release notes, I wonder 
about the version:

1/ requires now Java 5 instead of 1.3
2/ is binary compatible with 1.4
3/ does not remove deprecated stuff
4/ is using the same package name 
5/ is using the old Maven groupId
6/ adds a lot new stuff
7/ deprecates some stuff
8/ contains bug fixes

IMHO we started with 2.0 because we were not sure if topic 2/ and 3/ can be 
ensured for 1/ and it was not a primary goal. However, this turned out fine 
and 1/ has been never forcing a major version change in general. So, is 
there any other reason to call this release 2.0 instead of 1.5?

Cheers,
Jörg


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