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 00:17:45 GMT
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


Mime
View raw message