commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
Date Mon, 08 Nov 2010 02:02:35 GMT
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"<phil.steitz@gmail.com>  wrote:
>> On 11/7/10 7:03 PM, sebb wrote:
>>> On 7 November 2010 23:56, James Carman<james@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
>>>> <henning@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<james@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
>>>>>> <henning@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<james@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"<sebbaz@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


Mime
View raw message