You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henning Schmiedehausen <he...@schmiedehausen.org> on 2010/11/07 23:05:42 UTC
Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
It will be a new sub-project. commons-vfs-2.<x> and commons-vfs2-1.0
should be able to co-exist on the same classpath.
For maven reasons, it is not desirable to have <artifactId> shift its
internal packages (because Maven does not understand that 2.0 and 3.0
are not compatible) and commons-vfs and commons-vfs2 should not use
use the same packages.
So commons-vfs will continue to use org.apache.commons.vfs.* and
commons-vfs2 will use org.apache.commons.vfs2.*
And it must be possible to have both versions on the classpath without
clashing.
-h
On Sun, Nov 7, 2010 at 13:45, James Carman <ja...@carmanconsulting.com> wrote:
> If we release vfs2 and then we make changes that make it binary
> incompatible, then we have to go to 3 to do a new release. Am I
> missing something?
>
> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
> <he...@schmiedehausen.org> wrote:
>> No, that would be a vfs2. With new package names and everything. It
>> would not be intended to be drop in compatible.
>>
>> -h
>>
>> On Sun, Nov 7, 2010 at 10:53, James Carman <ja...@carmanconsulting.com> wrote:
>>> Make sure you stay compatible or it'll have to go to 3.0
>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" <GG...@seagullsoftware.com>
>>> wrote:
>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>>> henning@schmiedehausen.org> wrote:
>>>>
>>>>> I would suggest that we (and in fact I started hacking around with
>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>
>>>>
>>>> That's fine with me and my current work projects but I like a more
>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>> we can do a java 6 release.
>>>>
>>>> Gary
>>>>>
>>>>> -h
>>>>>
>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory <GG...@seagullsoftware.com>
>>> wrote:
>>>>>> On Nov 7, 2010, at 7:45, "sebb" <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 7 November 2010 02:17, Gary Gregory <GG...@seagullsoftware.com>
>>> wrote:
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Henning Schmiedehausen [mailto:henning@schmiedehausen.org]
>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>> To: Commons Developers List
>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>> later.
>>>>>>>>
>>>>>>>> Yes, release early, release often.
>>>>>>>>
>>>>>>>> I would encourage work to proceed immediately to implement this,
>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>
>>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>>
>>>>>>> I've started looking at generics.
>>>>>>>
>>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>>> soon
>>>>>>
>>>>>> Great news. It would be nice to release early release often a la XP with
>>> a 2.1 themed release 'java 5 optimized'
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -h
>>>>>>>>>
>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>
>>>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
>>> the
>>>>>>>>> requirement has been added to the web site main page. The test file
>>> for
>>>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
>>> improving
>>>>>>>>> the build time. Many of the messages from the test cases have been
>>> removed.
>>>>>>>>>>
>>>>>>>>>> [ ] +1 release it
>>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> tag:
>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>>
>>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>>
>>>>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>>>
>>>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>>>>> commons-vfs-2.0.jar
>>>>>>>>>> commons-vfs-2.0.pom
>>>>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>>>>>> commons-vfs-2.0.pom.asc
>>>>>>>>>> commons-vfs-2.0-sources.jar
>>>>>>>>>> commons-vfs-2.0.jar.asc
>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar.asc
>>>>>>>>>> commons-vfs-sandbox-2.0.jar.asc
>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar
>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar
>>>>>>>>>> commons-vfs-sandbox-2.0.pom
>>>>>>>>>> commons-vfs-sandbox-2.0.jar
>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>>>>>>>>>> commons-vfs-sandbox-2.0.pom.asc
>>>>>>>>>> commons-vfs-distribution-2.0-src.zip
>>>>>>>>>> commons-vfs-distribution-2.0.pom
>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz.asc
>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz
>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip
>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip.asc
>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz
>>>>>>>>>> commons-vfs-distribution-2.0-src.zip.asc
>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>>>>>>>>>> commons-vfs-distribution-2.0.pom.asc
>>>>>>>>>> commons-vfs-project-2.0-site.xml.asc
>>>>>>>>>> commons-vfs-project-2.0.pom
>>>>>>>>>> commons-vfs-project-2.0-site.xml
>>>>>>>>>> commons-vfs-project-2.0.pom.asc
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Nov 7, 2010 at 9:27 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> If this is rushing I'd hate to see slow. Releasing VFS 2.0 has been discussed several times over the last year or more. None of this is new information.
>
Rushing as in doing something before it's time to do it, not rushing
as in doing something quickly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Nov 7, 2010, at 6:18 PM, James Carman wrote:
> On Sun, Nov 7, 2010 at 9:15 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Is the goal to never do a release?
>>
>
> No, the goal is to not rush a release just to get something out there.
> If we will be knowingly setting our users up for failure (or worse
> "jar hell"), then I don't want to do a release that way.
>
If this is rushing I'd hate to see slow. Releasing VFS 2.0 has been discussed several times over the last year or more. None of this is new information.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Nov 7, 2010 at 9:15 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Is the goal to never do a release?
>
No, the goal is to not rush a release just to get something out there.
If we will be knowingly setting our users up for failure (or worse
"jar hell"), then I don't want to do a release that way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Nov 7, 2010, at 6:02 PM, Phil Steitz wrote:
> On 11/7/10 8:19 PM, James Carman wrote:
>> So you think that if there is no API break, then you don't bump major
>> version numbers? So what about vfs 2.0? Would you vote against it?
>
> I would not -1 the release, but I would encourage the RM to consider making it 1.x if there are no compat breaks.
>
As Sebb has shown there are compatibility breaks. The real issue here is that it has been far too long since a VFS release has been done.
I'm not sure why the version was bumped from 1.1 to 2.0, but it happened in March 2008, at least 8 months before I started working on the code. That change was 16 months after the prior release.
Is the goal to never do a release?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by sebb <se...@gmail.com>.
On 8 November 2010 07:32, Gary Gregory <GG...@seagullsoftware.com> wrote:
>> -----Original Message-----
>> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On
>> Behalf Of James Carman
>> Sent: Sunday, November 07, 2010 18:14
>> To: Commons Developers List
>> Subject: Re: Backwards incompatible changes and package names (was: Re: [VOTE]
>> Release Commons VFS 2.0)
>>
>> On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz <ph...@gmail.com> wrote:
>> > I would not -1 the release, but I would encourage the RM to consider making
>> > it 1.x if there are no compat breaks.
>> >
>>
>> So, how about now that we know there are compat breaks? I would -1
>> the release now that we know the API is in fact "broken" between 1 and
>> 2 and they're not doing the package/artifactId change (barring any
>> justification why we think it's okay).
>
> Well, that should settle it. API-breakage -> new major version -> package/artifactId change.
>
> So we can take this RC, do the above changes, then keep move on to a Java 5 themed release for 2.1.
I think we ought to remove the deprecations as well, otherwise they
cannot be removed until 3.0, which I assume will require yet another
package/artid change.
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: Backwards incompatible changes and package names (was: Re:
[VOTE] Release Commons VFS 2.0)
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Sunday, November 07, 2010 18:14
> To: Commons Developers List
> Subject: Re: Backwards incompatible changes and package names (was: Re: [VOTE]
> Release Commons VFS 2.0)
>
> On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz <ph...@gmail.com> wrote:
> > I would not -1 the release, but I would encourage the RM to consider making
> > it 1.x if there are no compat breaks.
> >
>
> So, how about now that we know there are compat breaks? I would -1
> the release now that we know the API is in fact "broken" between 1 and
> 2 and they're not doing the package/artifactId change (barring any
> justification why we think it's okay).
Well, that should settle it. API-breakage -> new major version -> package/artifactId change.
So we can take this RC, do the above changes, then keep move on to a Java 5 themed release for 2.1.
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: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz <ph...@gmail.com> wrote:
> I would not -1 the release, but I would encourage the RM to consider making
> it 1.x if there are no compat breaks.
>
So, how about now that we know there are compat breaks? I would -1
the release now that we know the API is in fact "broken" between 1 and
2 and they're not doing the package/artifactId change (barring any
justification why we think it's okay).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by Phil Steitz <ph...@gmail.com>.
On 11/7/10 8:19 PM, James Carman wrote:
> So you think that if there is no API break, then you don't bump major
> version numbers? So what about vfs 2.0? Would you vote against it?
I would not -1 the release, but I would encourage the RM to consider
making it 1.x if there are no compat breaks.
Phil
> On Nov 7, 2010 7:18 PM, "Phil Steitz"<ph...@gmail.com> wrote:
>> On 11/7/10 7:03 PM, sebb wrote:
>>> On 7 November 2010 23:56, James Carman<ja...@carmanconsulting.com> wrote:
>>>> It's not a new subproject. It's just a new version of the same
>>>> subproject. Trust me, I know about how the maven artifactId/package
>>>> name/classpath stuff works. I've had this discussion many times
>>>> before on this list. VFS is releasing its 2.0 release right now. If
>>>> you want to make binary incompatible changes, it has to bump its major
>>>> version number to 3 (along with artifactId/package change).
>>>
>>> Agreed.
>>>
>>>> This is
>>>> why I've argued that VFS 2.0 should actually be 1.1, so that we don't
>>>> introduce an inconsistency. The 2.x stuff should be in a vfs2
>>>> package, per our naming conventions. In my opinion, it's not enough
>>>
>>> AFAIK, we have not agreed that package name suffix == major version
> number.
>>
>> I used to be among those resisting this, but James' admirable
>> persistence has won me over :) For the components that are likely to
>> have any possibility of needing to appear twice on the classpath of
>> an application at least, I think the following convention makes sense:
>>
>> Major version bump<-> compatibility break in API<-> change package
>> name<-> change maven artifactId
>>
>> Bumping required JDK does not by itself force a compat break. I
>> guess it is possible that so much can be accomplished without any
>> breaks that a major version bump is warranted in some cases; but I
>> have never seen that happen. So I am +1 on trying to adhere to this
>> convention or at least explaining why not (in [math] for example we
>> perhaps lamely argue that classpath multiplicity is not likely).
>>
>> Phil
>>>
>>>> different to merit a 2.0 release. Not enough has been done.
>>>> Especially when you consider the version numbering madness that this
>>>> is going to cause.
>>>>
>>>> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
>>>> <he...@schmiedehausen.org> wrote:
>>>>> It will be a new sub-project. commons-vfs-2.<x> and commons-vfs2-1.0
>>>>> should be able to co-exist on the same classpath.
>>>>>
>>>>> For maven reasons, it is not desirable to have<artifactId> shift its
>>>>> internal packages (because Maven does not understand that 2.0 and 3.0
>>>>> are not compatible) and commons-vfs and commons-vfs2 should not use
>>>>> use the same packages.
>>>>>
>>>>> So commons-vfs will continue to use org.apache.commons.vfs.* and
>>>>> commons-vfs2 will use org.apache.commons.vfs2.*
>>>>>
>>>>> And it must be possible to have both versions on the classpath without
>>>>> clashing.
>>>>>
>>>>> -h
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Nov 7, 2010 at 13:45, James Carman<ja...@carmanconsulting.com>
> wrote:
>>>>>> If we release vfs2 and then we make changes that make it binary
>>>>>> incompatible, then we have to go to 3 to do a new release. Am I
>>>>>> missing something?
>>>>>>
>>>>>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>>>>> <he...@schmiedehausen.org> wrote:
>>>>>>> No, that would be a vfs2. With new package names and everything. It
>>>>>>> would not be intended to be drop in compatible.
>>>>>>>
>>>>>>> -h
>>>>>>>
>>>>>>> On Sun, Nov 7, 2010 at 10:53, James Carman<ja...@carmanconsulting.com>
> wrote:
>>>>>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory"<GGregory@seagullsoftware.com
>>
>>>>>>>> wrote:
>>>>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<
>>>>>>>> henning@schmiedehausen.org> wrote:
>>>>>>>>>
>>>>>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That's fine with me and my current work projects but I like a more
>>>>>>>> iterative process where we can generify the code on java 5 for a
> 2.1. Then
>>>>>>>> we can do a java 6 release.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> -h
>>>>>>>>>>
>>>>>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory<
> GGregory@seagullsoftware.com>
>>>>>>>> wrote:
>>>>>>>>>>> On Nov 7, 2010, at 7:45, "sebb"<se...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7 November 2010 02:17, Gary Gregory<
> GGregory@seagullsoftware.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Henning Schmiedehausen [mailto:
> henning@schmiedehausen.org]
>>>>>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>>>>>> To: Commons Developers List
>>>>>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>>>>>> - If deprecated APIs are still around, we can always remove
> them
>>>>>>>> later.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, release early, release often.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would encourage work to proceed immediately to implement
> this,
>>>>>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>>>>>
>>>>>>>>>>>> I've already done the main annotations (@Override and
> @Deprecation)
>>>>>>>>>>>>
>>>>>>>>>>>> I've started looking at generics.
>>>>>>>>>>>>
>>>>>>>>>>>> There's rather a lot of changes to fix all the Java 1.5
> warnings, so
>>>>>>>>>>>> it will probably have to be done in stages, but I can start
> committing
>>>>>>>>>>>> soon
>>>>>>>>>>>
>>>>>>>>>>> Great news. It would be nice to release early release often a la
> XP with
>>>>>>>> a 2.1 themed release 'java 5 optimized'
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -h
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers<
> ralph.goers@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since the last candidate the jdk version has been changed to
> 1.5 and
>>>>>>>> the
>>>>>>>>>>>>>> requirement has been added to the web site main page. The test
> file
>>>>>>>> for
>>>>>>>>>>>>>> LargeTarTestCase has been added to the test-data directory,
> greatly
>>>>>>>> improving
>>>>>>>>>>>>>> the build time. Many of the messages from the test cases have
> been
>>>>>>>> removed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ ] +1 release it
>>>>>>>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> tag:
>>>>>>>>
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The following artifacts have been staged to the Apache Nexus
> Staging
>>>>>>>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>>>>>>>
>>>>>>>>
> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>>>>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>>>>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>>>>>>>>>> commons-vfs-2.0.jar
>>>>>>>>>>>>>>> commons-vfs-2.0.pom
>>>>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>>>>>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>>>>>>>>>>> commons-vfs-2.0.pom.asc
>>>>>>>>>>>>>>> commons-vfs-2.0-sources.jar
>>>>>>>>>>>>>>> commons-vfs-2.0.jar.asc
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar.asc
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar.asc
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom.asc
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0.pom
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz.asc
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip.asc
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip.asc
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>>>>>>>>>>>>>>> commons-vfs-distribution-2.0.pom.asc
>>>>>>>>>>>>>>> commons-vfs-project-2.0-site.xml.asc
>>>>>>>>>>>>>>> commons-vfs-project-2.0.pom
>>>>>>>>>>>>>>> commons-vfs-project-2.0-site.xml
>>>>>>>>>>>>>>> commons-vfs-project-2.0.pom.asc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
> ---------------------------------------------------------------------
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
> ---------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by James Carman <ja...@carmanconsulting.com>.
So you think that if there is no API break, then you don't bump major
version numbers? So what about vfs 2.0? Would you vote against it?
On Nov 7, 2010 7:18 PM, "Phil Steitz" <ph...@gmail.com> wrote:
> On 11/7/10 7:03 PM, sebb wrote:
>> On 7 November 2010 23:56, James Carman<ja...@carmanconsulting.com> wrote:
>>> It's not a new subproject. It's just a new version of the same
>>> subproject. Trust me, I know about how the maven artifactId/package
>>> name/classpath stuff works. I've had this discussion many times
>>> before on this list. VFS is releasing its 2.0 release right now. If
>>> you want to make binary incompatible changes, it has to bump its major
>>> version number to 3 (along with artifactId/package change).
>>
>> Agreed.
>>
>>> This is
>>> why I've argued that VFS 2.0 should actually be 1.1, so that we don't
>>> introduce an inconsistency. The 2.x stuff should be in a vfs2
>>> package, per our naming conventions. In my opinion, it's not enough
>>
>> AFAIK, we have not agreed that package name suffix == major version
number.
>
> I used to be among those resisting this, but James' admirable
> persistence has won me over :) For the components that are likely to
> have any possibility of needing to appear twice on the classpath of
> an application at least, I think the following convention makes sense:
>
> Major version bump <-> compatibility break in API <-> change package
> name <-> change maven artifactId
>
> Bumping required JDK does not by itself force a compat break. I
> guess it is possible that so much can be accomplished without any
> breaks that a major version bump is warranted in some cases; but I
> have never seen that happen. So I am +1 on trying to adhere to this
> convention or at least explaining why not (in [math] for example we
> perhaps lamely argue that classpath multiplicity is not likely).
>
> Phil
>>
>>> different to merit a 2.0 release. Not enough has been done.
>>> Especially when you consider the version numbering madness that this
>>> is going to cause.
>>>
>>> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
>>> <he...@schmiedehausen.org> wrote:
>>>> It will be a new sub-project. commons-vfs-2.<x> and commons-vfs2-1.0
>>>> should be able to co-exist on the same classpath.
>>>>
>>>> For maven reasons, it is not desirable to have<artifactId> shift its
>>>> internal packages (because Maven does not understand that 2.0 and 3.0
>>>> are not compatible) and commons-vfs and commons-vfs2 should not use
>>>> use the same packages.
>>>>
>>>> So commons-vfs will continue to use org.apache.commons.vfs.* and
>>>> commons-vfs2 will use org.apache.commons.vfs2.*
>>>>
>>>> And it must be possible to have both versions on the classpath without
>>>> clashing.
>>>>
>>>> -h
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Nov 7, 2010 at 13:45, James Carman<ja...@carmanconsulting.com>
wrote:
>>>>> If we release vfs2 and then we make changes that make it binary
>>>>> incompatible, then we have to go to 3 to do a new release. Am I
>>>>> missing something?
>>>>>
>>>>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>>>> <he...@schmiedehausen.org> wrote:
>>>>>> No, that would be a vfs2. With new package names and everything. It
>>>>>> would not be intended to be drop in compatible.
>>>>>>
>>>>>> -h
>>>>>>
>>>>>> On Sun, Nov 7, 2010 at 10:53, James Carman<ja...@carmanconsulting.com>
wrote:
>>>>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory"<GGregory@seagullsoftware.com
>
>>>>>>> wrote:
>>>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<
>>>>>>> henning@schmiedehausen.org> wrote:
>>>>>>>>
>>>>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's fine with me and my current work projects but I like a more
>>>>>>> iterative process where we can generify the code on java 5 for a
2.1. Then
>>>>>>> we can do a java 6 release.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> -h
>>>>>>>>>
>>>>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory<
GGregory@seagullsoftware.com>
>>>>>>> wrote:
>>>>>>>>>> On Nov 7, 2010, at 7:45, "sebb"<se...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 7 November 2010 02:17, Gary Gregory<
GGregory@seagullsoftware.com>
>>>>>>> wrote:
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Henning Schmiedehausen [mailto:
henning@schmiedehausen.org]
>>>>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>>>>> To: Commons Developers List
>>>>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>>>>> - If deprecated APIs are still around, we can always remove
them
>>>>>>> later.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, release early, release often.
>>>>>>>>>>>>
>>>>>>>>>>>> I would encourage work to proceed immediately to implement
this,
>>>>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>>>>
>>>>>>>>>>> I've already done the main annotations (@Override and
@Deprecation)
>>>>>>>>>>>
>>>>>>>>>>> I've started looking at generics.
>>>>>>>>>>>
>>>>>>>>>>> There's rather a lot of changes to fix all the Java 1.5
warnings, so
>>>>>>>>>>> it will probably have to be done in stages, but I can start
committing
>>>>>>>>>>> soon
>>>>>>>>>>
>>>>>>>>>> Great news. It would be nice to release early release often a la
XP with
>>>>>>> a 2.1 themed release 'java 5 optimized'
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -h
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers<
ralph.goers@dslextreme.com>
>>>>>>> wrote:
>>>>>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since the last candidate the jdk version has been changed to
1.5 and
>>>>>>> the
>>>>>>>>>>>>> requirement has been added to the web site main page. The test
file
>>>>>>> for
>>>>>>>>>>>>> LargeTarTestCase has been added to the test-data directory,
greatly
>>>>>>> improving
>>>>>>>>>>>>> the build time. Many of the messages from the test cases have
been
>>>>>>> removed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ ] +1 release it
>>>>>>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tag:
>>>>>>>
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The following artifacts have been staged to the Apache Nexus
Staging
>>>>>>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>>>>>>
>>>>>>>
https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>>>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>>>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>>>>>>>>> commons-vfs-2.0.jar
>>>>>>>>>>>>>> commons-vfs-2.0.pom
>>>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>>>>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>>>>>>>>>> commons-vfs-2.0.pom.asc
>>>>>>>>>>>>>> commons-vfs-2.0-sources.jar
>>>>>>>>>>>>>> commons-vfs-2.0.jar.asc
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar.asc
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar.asc
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>>>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom.asc
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip
>>>>>>>>>>>>>> commons-vfs-distribution-2.0.pom
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz.asc
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip.asc
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip.asc
>>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>>>>>>>>>>>>>> commons-vfs-distribution-2.0.pom.asc
>>>>>>>>>>>>>> commons-vfs-project-2.0-site.xml.asc
>>>>>>>>>>>>>> commons-vfs-project-2.0.pom
>>>>>>>>>>>>>> commons-vfs-project-2.0-site.xml
>>>>>>>>>>>>>> commons-vfs-project-2.0.pom.asc
>>>>>>>>>>>>>
>>>>>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by Phil Steitz <ph...@gmail.com>.
On 11/7/10 7:03 PM, sebb wrote:
> On 7 November 2010 23:56, James Carman<ja...@carmanconsulting.com> wrote:
>> It's not a new subproject. It's just a new version of the same
>> subproject. Trust me, I know about how the maven artifactId/package
>> name/classpath stuff works. I've had this discussion many times
>> before on this list. VFS is releasing its 2.0 release right now. If
>> you want to make binary incompatible changes, it has to bump its major
>> version number to 3 (along with artifactId/package change).
>
> Agreed.
>
>> This is
>> why I've argued that VFS 2.0 should actually be 1.1, so that we don't
>> introduce an inconsistency. The 2.x stuff should be in a vfs2
>> package, per our naming conventions. In my opinion, it's not enough
>
> AFAIK, we have not agreed that package name suffix == major version number.
I used to be among those resisting this, but James' admirable
persistence has won me over :) For the components that are likely to
have any possibility of needing to appear twice on the classpath of
an application at least, I think the following convention makes sense:
Major version bump <-> compatibility break in API <-> change package
name <-> change maven artifactId
Bumping required JDK does not by itself force a compat break. I
guess it is possible that so much can be accomplished without any
breaks that a major version bump is warranted in some cases; but I
have never seen that happen. So I am +1 on trying to adhere to this
convention or at least explaining why not (in [math] for example we
perhaps lamely argue that classpath multiplicity is not likely).
Phil
>
>> different to merit a 2.0 release. Not enough has been done.
>> Especially when you consider the version numbering madness that this
>> is going to cause.
>>
>> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
>> <he...@schmiedehausen.org> wrote:
>>> It will be a new sub-project. commons-vfs-2.<x> and commons-vfs2-1.0
>>> should be able to co-exist on the same classpath.
>>>
>>> For maven reasons, it is not desirable to have<artifactId> shift its
>>> internal packages (because Maven does not understand that 2.0 and 3.0
>>> are not compatible) and commons-vfs and commons-vfs2 should not use
>>> use the same packages.
>>>
>>> So commons-vfs will continue to use org.apache.commons.vfs.* and
>>> commons-vfs2 will use org.apache.commons.vfs2.*
>>>
>>> And it must be possible to have both versions on the classpath without
>>> clashing.
>>>
>>> -h
>>>
>>>
>>>
>>>
>>> On Sun, Nov 7, 2010 at 13:45, James Carman<ja...@carmanconsulting.com> wrote:
>>>> If we release vfs2 and then we make changes that make it binary
>>>> incompatible, then we have to go to 3 to do a new release. Am I
>>>> missing something?
>>>>
>>>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>>> <he...@schmiedehausen.org> wrote:
>>>>> No, that would be a vfs2. With new package names and everything. It
>>>>> would not be intended to be drop in compatible.
>>>>>
>>>>> -h
>>>>>
>>>>> On Sun, Nov 7, 2010 at 10:53, James Carman<ja...@carmanconsulting.com> wrote:
>>>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory"<GG...@seagullsoftware.com>
>>>>>> wrote:
>>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<
>>>>>> henning@schmiedehausen.org> wrote:
>>>>>>>
>>>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>>>
>>>>>>>
>>>>>>> That's fine with me and my current work projects but I like a more
>>>>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>>>>> we can do a java 6 release.
>>>>>>>
>>>>>>> Gary
>>>>>>>>
>>>>>>>> -h
>>>>>>>>
>>>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory<GG...@seagullsoftware.com>
>>>>>> wrote:
>>>>>>>>> On Nov 7, 2010, at 7:45, "sebb"<se...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7 November 2010 02:17, Gary Gregory<GG...@seagullsoftware.com>
>>>>>> wrote:
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Henning Schmiedehausen [mailto:henning@schmiedehausen.org]
>>>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>>>> To: Commons Developers List
>>>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>>>>> later.
>>>>>>>>>>>
>>>>>>>>>>> Yes, release early, release often.
>>>>>>>>>>>
>>>>>>>>>>> I would encourage work to proceed immediately to implement this,
>>>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>>>
>>>>>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>>>>>
>>>>>>>>>> I've started looking at generics.
>>>>>>>>>>
>>>>>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>>>>>> soon
>>>>>>>>>
>>>>>>>>> Great news. It would be nice to release early release often a la XP with
>>>>>> a 2.1 themed release 'java 5 optimized'
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -h
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers<ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
>>>>>> the
>>>>>>>>>>>> requirement has been added to the web site main page. The test file
>>>>>> for
>>>>>>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
>>>>>> improving
>>>>>>>>>>>> the build time. Many of the messages from the test cases have been
>>>>>> removed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ ] +1 release it
>>>>>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> tag:
>>>>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>>>>>
>>>>>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>>>>>
>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>>>>>>
>>>>>>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>>>>>>>> commons-vfs-2.0.jar
>>>>>>>>>>>>> commons-vfs-2.0.pom
>>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>>>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>>>>>>>>> commons-vfs-2.0.pom.asc
>>>>>>>>>>>>> commons-vfs-2.0-sources.jar
>>>>>>>>>>>>> commons-vfs-2.0.jar.asc
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar.asc
>>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar.asc
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar
>>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom
>>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar
>>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom.asc
>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip
>>>>>>>>>>>>> commons-vfs-distribution-2.0.pom
>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz.asc
>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz
>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip
>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip.asc
>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz
>>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip.asc
>>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>>>>>>>>>>>>> commons-vfs-distribution-2.0.pom.asc
>>>>>>>>>>>>> commons-vfs-project-2.0-site.xml.asc
>>>>>>>>>>>>> commons-vfs-project-2.0.pom
>>>>>>>>>>>>> commons-vfs-project-2.0-site.xml
>>>>>>>>>>>>> commons-vfs-project-2.0.pom.asc
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by sebb <se...@gmail.com>.
On 7 November 2010 23:56, James Carman <ja...@carmanconsulting.com> wrote:
> It's not a new subproject. It's just a new version of the same
> subproject. Trust me, I know about how the maven artifactId/package
> name/classpath stuff works. I've had this discussion many times
> before on this list. VFS is releasing its 2.0 release right now. If
> you want to make binary incompatible changes, it has to bump its major
> version number to 3 (along with artifactId/package change).
Agreed.
> This is
> why I've argued that VFS 2.0 should actually be 1.1, so that we don't
> introduce an inconsistency. The 2.x stuff should be in a vfs2
> package, per our naming conventions. In my opinion, it's not enough
AFAIK, we have not agreed that package name suffix == major version number.
> different to merit a 2.0 release. Not enough has been done.
> Especially when you consider the version numbering madness that this
> is going to cause.
>
> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
> <he...@schmiedehausen.org> wrote:
>> It will be a new sub-project. commons-vfs-2.<x> and commons-vfs2-1.0
>> should be able to co-exist on the same classpath.
>>
>> For maven reasons, it is not desirable to have <artifactId> shift its
>> internal packages (because Maven does not understand that 2.0 and 3.0
>> are not compatible) and commons-vfs and commons-vfs2 should not use
>> use the same packages.
>>
>> So commons-vfs will continue to use org.apache.commons.vfs.* and
>> commons-vfs2 will use org.apache.commons.vfs2.*
>>
>> And it must be possible to have both versions on the classpath without
>> clashing.
>>
>> -h
>>
>>
>>
>>
>> On Sun, Nov 7, 2010 at 13:45, James Carman <ja...@carmanconsulting.com> wrote:
>>> If we release vfs2 and then we make changes that make it binary
>>> incompatible, then we have to go to 3 to do a new release. Am I
>>> missing something?
>>>
>>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>>> <he...@schmiedehausen.org> wrote:
>>>> No, that would be a vfs2. With new package names and everything. It
>>>> would not be intended to be drop in compatible.
>>>>
>>>> -h
>>>>
>>>> On Sun, Nov 7, 2010 at 10:53, James Carman <ja...@carmanconsulting.com> wrote:
>>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" <GG...@seagullsoftware.com>
>>>>> wrote:
>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>>>>> henning@schmiedehausen.org> wrote:
>>>>>>
>>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>>
>>>>>>
>>>>>> That's fine with me and my current work projects but I like a more
>>>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>>>> we can do a java 6 release.
>>>>>>
>>>>>> Gary
>>>>>>>
>>>>>>> -h
>>>>>>>
>>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory <GG...@seagullsoftware.com>
>>>>> wrote:
>>>>>>>> On Nov 7, 2010, at 7:45, "sebb" <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 7 November 2010 02:17, Gary Gregory <GG...@seagullsoftware.com>
>>>>> wrote:
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Henning Schmiedehausen [mailto:henning@schmiedehausen.org]
>>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>>> To: Commons Developers List
>>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>>>> later.
>>>>>>>>>>
>>>>>>>>>> Yes, release early, release often.
>>>>>>>>>>
>>>>>>>>>> I would encourage work to proceed immediately to implement this,
>>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>>
>>>>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>>>>
>>>>>>>>> I've started looking at generics.
>>>>>>>>>
>>>>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>>>>> soon
>>>>>>>>
>>>>>>>> Great news. It would be nice to release early release often a la XP with
>>>>> a 2.1 themed release 'java 5 optimized'
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -h
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>>>
>>>>>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
>>>>> the
>>>>>>>>>>> requirement has been added to the web site main page. The test file
>>>>> for
>>>>>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
>>>>> improving
>>>>>>>>>>> the build time. Many of the messages from the test cases have been
>>>>> removed.
>>>>>>>>>>>>
>>>>>>>>>>>> [ ] +1 release it
>>>>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> tag:
>>>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>>>>
>>>>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>>>>
>>>>>>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>>>>
>>>>> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>>>>>
>>>>>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>>>>>>> commons-vfs-2.0.jar
>>>>>>>>>>>> commons-vfs-2.0.pom
>>>>>>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>>>>>>>> commons-vfs-2.0.pom.asc
>>>>>>>>>>>> commons-vfs-2.0-sources.jar
>>>>>>>>>>>> commons-vfs-2.0.jar.asc
>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar.asc
>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar.asc
>>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar
>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar
>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom
>>>>>>>>>>>> commons-vfs-sandbox-2.0.jar
>>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>>>>>>>>>>>> commons-vfs-sandbox-2.0.pom.asc
>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip
>>>>>>>>>>>> commons-vfs-distribution-2.0.pom
>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz.asc
>>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz
>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip
>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip.asc
>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz
>>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip.asc
>>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>>>>>>>>>>>> commons-vfs-distribution-2.0.pom.asc
>>>>>>>>>>>> commons-vfs-project-2.0-site.xml.asc
>>>>>>>>>>>> commons-vfs-project-2.0.pom
>>>>>>>>>>>> commons-vfs-project-2.0-site.xml
>>>>>>>>>>>> commons-vfs-project-2.0.pom.asc
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Backwards incompatible changes and package names (was: Re: [VOTE]
Release Commons VFS 2.0)
Posted by James Carman <ja...@carmanconsulting.com>.
It's not a new subproject. It's just a new version of the same
subproject. Trust me, I know about how the maven artifactId/package
name/classpath stuff works. I've had this discussion many times
before on this list. VFS is releasing its 2.0 release right now. If
you want to make binary incompatible changes, it has to bump its major
version number to 3 (along with artifactId/package change). This is
why I've argued that VFS 2.0 should actually be 1.1, so that we don't
introduce an inconsistency. The 2.x stuff should be in a vfs2
package, per our naming conventions. In my opinion, it's not enough
different to merit a 2.0 release. Not enough has been done.
Especially when you consider the version numbering madness that this
is going to cause.
On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen
<he...@schmiedehausen.org> wrote:
> It will be a new sub-project. commons-vfs-2.<x> and commons-vfs2-1.0
> should be able to co-exist on the same classpath.
>
> For maven reasons, it is not desirable to have <artifactId> shift its
> internal packages (because Maven does not understand that 2.0 and 3.0
> are not compatible) and commons-vfs and commons-vfs2 should not use
> use the same packages.
>
> So commons-vfs will continue to use org.apache.commons.vfs.* and
> commons-vfs2 will use org.apache.commons.vfs2.*
>
> And it must be possible to have both versions on the classpath without
> clashing.
>
> -h
>
>
>
>
> On Sun, Nov 7, 2010 at 13:45, James Carman <ja...@carmanconsulting.com> wrote:
>> If we release vfs2 and then we make changes that make it binary
>> incompatible, then we have to go to 3 to do a new release. Am I
>> missing something?
>>
>> On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
>> <he...@schmiedehausen.org> wrote:
>>> No, that would be a vfs2. With new package names and everything. It
>>> would not be intended to be drop in compatible.
>>>
>>> -h
>>>
>>> On Sun, Nov 7, 2010 at 10:53, James Carman <ja...@carmanconsulting.com> wrote:
>>>> Make sure you stay compatible or it'll have to go to 3.0
>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" <GG...@seagullsoftware.com>
>>>> wrote:
>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
>>>> henning@schmiedehausen.org> wrote:
>>>>>
>>>>>> I would suggest that we (and in fact I started hacking around with
>>>>>> this) release a vfs2 which is Java6+ only and fully generified.
>>>>>>
>>>>>
>>>>> That's fine with me and my current work projects but I like a more
>>>> iterative process where we can generify the code on java 5 for a 2.1. Then
>>>> we can do a java 6 release.
>>>>>
>>>>> Gary
>>>>>>
>>>>>> -h
>>>>>>
>>>>>> On Sun, Nov 7, 2010 at 08:22, Gary Gregory <GG...@seagullsoftware.com>
>>>> wrote:
>>>>>>> On Nov 7, 2010, at 7:45, "sebb" <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 7 November 2010 02:17, Gary Gregory <GG...@seagullsoftware.com>
>>>> wrote:
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Henning Schmiedehausen [mailto:henning@schmiedehausen.org]
>>>>>>>>>> Sent: Saturday, November 06, 2010 19:03
>>>>>>>>>> To: Commons Developers List
>>>>>>>>>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> - I don't think that "has warnings" is a problem
>>>>>>>>>> - If deprecated APIs are still around, we can always remove them
>>>> later.
>>>>>>>>>
>>>>>>>>> Yes, release early, release often.
>>>>>>>>>
>>>>>>>>> I would encourage work to proceed immediately to implement this,
>>>> generics, and whatever Java 5 changes we can take advantage of.
>>>>>>>>
>>>>>>>> I've already done the main annotations (@Override and @Deprecation)
>>>>>>>>
>>>>>>>> I've started looking at generics.
>>>>>>>>
>>>>>>>> There's rather a lot of changes to fix all the Java 1.5 warnings, so
>>>>>>>> it will probably have to be done in stages, but I can start committing
>>>>>>>> soon
>>>>>>>
>>>>>>> Great news. It would be nice to release early release often a la XP with
>>>> a 2.1 themed release 'java 5 optimized'
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -h
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>>>>>>>> This is a vote to release Apache Commons VFS 2.0.
>>>>>>>>>>>
>>>>>>>>>>> Since the last candidate the jdk version has been changed to 1.5 and
>>>> the
>>>>>>>>>> requirement has been added to the web site main page. The test file
>>>> for
>>>>>>>>>> LargeTarTestCase has been added to the test-data directory, greatly
>>>> improving
>>>>>>>>>> the build time. Many of the messages from the test cases have been
>>>> removed.
>>>>>>>>>>>
>>>>>>>>>>> [ ] +1 release it
>>>>>>>>>>> [ ] +0 go ahead I don't care
>>>>>>>>>>> [ ] -1 no, do not release it because...
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> tag:
>>>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-
>>>>>>>>>> project-2.0/ (revision 1031749)
>>>>>>>>>>>
>>>>>>>>>>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
>>>>>>>>>>>
>>>>>>>>>>> The following artifacts have been staged to the Apache Nexus Staging
>>>>>>>>>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246)
>>>>>>>>>>
>>>> https://repository.apache.org/content/repositories/orgapachecommons-038/
>>>>>>>>>>>
>>>>>>>>>>> commons-vfs-examples-2.0.jar
>>>>>>>>>>> commons-vfs-examples-2.0.pom
>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar
>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar
>>>>>>>>>>> commons-vfs-examples-2.0.jar.asc
>>>>>>>>>>> commons-vfs-examples-2.0-sources.jar.asc
>>>>>>>>>>> commons-vfs-examples-2.0.pom.asc
>>>>>>>>>>> commons-vfs-examples-2.0-javadoc.jar.asc
>>>>>>>>>>> commons-vfs-2.0-tests.jar
>>>>>>>>>>> commons-vfs-2.0-test-sources.jar.asc
>>>>>>>>>>> commons-vfs-2.0-sources.jar.asc
>>>>>>>>>>> commons-vfs-2.0.jar
>>>>>>>>>>> commons-vfs-2.0.pom
>>>>>>>>>>> commons-vfs-2.0-test-sources.jar
>>>>>>>>>>> commons-vfs-2.0-javadoc.jar
>>>>>>>>>>> commons-vfs-2.0-javadoc.jar.asc
>>>>>>>>>>> commons-vfs-2.0-tests.jar.asc
>>>>>>>>>>> commons-vfs-2.0.pom.asc
>>>>>>>>>>> commons-vfs-2.0-sources.jar
>>>>>>>>>>> commons-vfs-2.0.jar.asc
>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar.asc
>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar
>>>>>>>>>>> commons-vfs-sandbox-2.0-tests.jar
>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar.asc
>>>>>>>>>>> commons-vfs-sandbox-2.0-sources.jar.asc
>>>>>>>>>>> commons-vfs-sandbox-2.0.jar.asc
>>>>>>>>>>> commons-vfs-sandbox-2.0-test-sources.jar
>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar
>>>>>>>>>>> commons-vfs-sandbox-2.0.pom
>>>>>>>>>>> commons-vfs-sandbox-2.0.jar
>>>>>>>>>>> commons-vfs-sandbox-2.0-javadoc.jar.asc
>>>>>>>>>>> commons-vfs-sandbox-2.0.pom.asc
>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip
>>>>>>>>>>> commons-vfs-distribution-2.0.pom
>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz.asc
>>>>>>>>>>> commons-vfs-distribution-2.0-src.tar.gz
>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip
>>>>>>>>>>> commons-vfs-distribution-2.0-bin.zip.asc
>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz
>>>>>>>>>>> commons-vfs-distribution-2.0-src.zip.asc
>>>>>>>>>>> commons-vfs-distribution-2.0-bin.tar.gz.asc
>>>>>>>>>>> commons-vfs-distribution-2.0.pom.asc
>>>>>>>>>>> commons-vfs-project-2.0-site.xml.asc
>>>>>>>>>>> commons-vfs-project-2.0.pom
>>>>>>>>>>> commons-vfs-project-2.0-site.xml
>>>>>>>>>>> commons-vfs-project-2.0.pom.asc
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org