[IO] 2.0 RC2 available for review

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[IO] 2.0 RC2 available for review

Niall Pemberton
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Jörg Schaible
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Niall Pemberton
On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

James Carman
So, call it 1.5

On Wed, Oct 6, 2010 at 6:49 AM, Niall Pemberton
<[hidden email]> wrote:

> On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

jodastephen
In reply to this post by Niall Pemberton
On 6 October 2010 11:49, Niall Pemberton <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Jörg Schaible
In reply to this post by James Carman

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Niall Pemberton
On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Michael Wooten-2
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
<[hidden email]> wrote:

> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Paul Benedict
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 <[hidden email]> 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
> <[hidden email]> wrote:
>> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Matt Benson-2
In reply to this post by Michael Wooten-2

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
> <[hidden email]> wrote:
>> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Niall Pemberton
On Wed, Oct 6, 2010 at 3:36 PM, Matt Benson <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On Wed, Oct 6, 2010 at 12:44 PM, Jörg Schaible <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

James Carman
On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Niall Pemberton
On Wed, Oct 6, 2010 at 4:20 PM, James Carman <[hidden email]> wrote:

> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

sebb-2-2
In reply to this post by James Carman
On 6 October 2010 16:20, James Carman <[hidden email]> wrote:

> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

James Carman
In reply to this post by Niall Pemberton
On Wed, Oct 6, 2010 at 12:08 PM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Jörg Schaible
In reply to this post by Niall Pemberton
Hi guys,

Niall Pemberton wrote:

> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <[hidden email]>
> wrote:
>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Paul Benedict
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 <[hidden email]> wrote:

> Hi guys,
>
> Niall Pemberton wrote:
>
>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <[hidden email]>
>> wrote:
>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Niall Pemberton
On Wed, Oct 6, 2010 at 5:48 PM, Paul Benedict <[hidden email]> 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 <[hidden email]> wrote:
>> Hi guys,
>>
>> Niall Pemberton wrote:
>>
>>> On Wed, Oct 6, 2010 at 4:20 PM, James Carman <[hidden email]>
>>> wrote:
>>>> On Wed, Oct 6, 2010 at 11:00 AM, Niall Pemberton
>>>> <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

James Carman
On Wed, Oct 6, 2010 at 12:54 PM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] 2.0 RC2 available for review

Gary Gregory
In reply to this post by Niall Pemberton
On Oct 6, 2010, at 3:50, "Niall Pemberton" <[hidden email]> wrote:

> On Wed, Oct 6, 2010 at 8:18 AM, Jörg Schaible <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12