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" <phil.ste...@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
>>> <henn...@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
>>>>> <henn...@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"<ggreg...@seagullsoftware.com
>
>>>>>>> wrote:
>>>>>>>> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"<
>>>>>>> henn...@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<
ggreg...@seagullsoftware.com>
>>>>>>> wrote:
>>>>>>>>>> On Nov 7, 2010, at 7:45, "sebb"<seb...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 7 November 2010 02:17, Gary Gregory<
ggreg...@seagullsoftware.com>
>>>>>>> wrote:
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Henning Schmiedehausen [mailto:
henn...@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.go...@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-unsubscr...@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
