Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 97025 invoked from network); 8 Nov 2010 01:19:17 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Nov 2010 01:19:17 -0000 Received: (qmail 74827 invoked by uid 500); 8 Nov 2010 01:19:48 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 74700 invoked by uid 500); 8 Nov 2010 01:19:48 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 74692 invoked by uid 99); 8 Nov 2010 01:19:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 01:19:48 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.171] (HELO mail-wy0-f171.google.com) (74.125.82.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 01:19:44 +0000 Received: by wyb39 with SMTP id 39so4969211wyb.30 for ; Sun, 07 Nov 2010 17:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.142.208 with SMTP id r16mr4738850wbu.140.1289179160797; Sun, 07 Nov 2010 17:19:20 -0800 (PST) Sender: jcarman@carmanconsulting.com Received: by 10.227.27.205 with HTTP; Sun, 7 Nov 2010 17:19:20 -0800 (PST) Received: by 10.227.27.205 with HTTP; Sun, 7 Nov 2010 17:19:20 -0800 (PST) In-Reply-To: <4CD741A9.8050803@gmail.com> References: <4CD741A9.8050803@gmail.com> Date: Sun, 7 Nov 2010 20:19:20 -0500 X-Google-Sender-Auth: Hcix94egfSMFeuFcq84QV8R26YA Message-ID: Subject: Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0) From: James Carman To: Commons Developers List Content-Type: multipart/alternative; boundary=0016367fb149ee6331049480699a --0016367fb149ee6331049480699a Content-Type: text/plain; charset=ISO-8859-1 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" wrote: > On 11/7/10 7:03 PM, sebb wrote: >> On 7 November 2010 23:56, James Carman 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 >>> wrote: >>>> It will be a new sub-project. commons-vfs-2. and commons-vfs2-1.0 >>>> should be able to co-exist on the same classpath. >>>> >>>> For maven reasons, it is not desirable to have 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 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 >>>>> 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 wrote: >>>>>>> Make sure you stay compatible or it'll have to go to 3.0 >>>>>>> On Nov 7, 2010 11:44 AM, "Gary Gregory" >>>>>>> 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" 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 > --0016367fb149ee6331049480699a--