Not to derail the conversation, but my opinion is (and has been for several years) that VFS 3.0 should be modified to use java.nio.file.FileSystem and FileStore. I don’t think it makes much sense for VFS to have its own constructs any more.
Ralph > On Apr 28, 2016, at 3:41 PM, e...@zusammenkunft.net wrote: > > The components have been updated multiple times. The more we modernize it > (including new java version) the less useful the release will be as a drop-in > replacement for 2.0. I had the impression some bug reporters would like that. > (Just for the record I wondered about having an additional a 2.0.1. Branch > but I doubt we find resources for that painful task). It would allow us to > release 3.0 (with java 8)... > > If we try to stick to 2.1 I would not do (more) dependency upgrades and Java > 7 later (having said that we already switched to java 6 but that offers way > more important features than we wohld use in 7 (what java 7 feature you would > want to use?) > > But I am fine with both > > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: Gary Gregory <garydgreg...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Cc: Josh Elser <els...@apache.org> > Sent: Fr., 29 Apr. 2016 0:16 > Subject: Re: [VFS] 2.1 Release Plan > > Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party > components? > > Gary > > On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> Yes, there is a BC breakage for providers, is that grounds for a package >> and Maven coordinate rename to vfs3? >> >> Gary >> >> On Tue, Apr 26, 2016 at 12:31 PM, Bernd Eckenfels <e...@zusammenkunft.net> >> wrote: >> >>> Hello Josh, >>> >>> I think a VFS 2.1 release would be cool and it is good that you >>> volunteer, so I dont object. My latest todo list is here: >>> >>> https://wiki.apache.org/commons/VfsReleaseState >>> >>> As you can see, I did plan to do the release and did quite some work to >>> get VFS into a releaseable state. But I am quite happy that you want to >>> step in as I havent had the time to do the procedure yet. >>> >>> And this is not the actual release procedure (which should be doable as >>> long as you do not try to use the release-plugin and be careful about >>> the multi-module+sandbox nature of VFS (as opposed to other commons >>> projects)). Also be carefull about branch and tag namings (the SVN is a >>> bit messy in this regard). >>> >>> My main concern I am afraid I would not have enough capacity is because >>> of the Clirr report and a lot of partially incompatible changes. Most >>> of them only affect providers if they do not properly use abstract base >>> classes, but still the list of Clirr violations is long and developers >>> here have not yet voiced if they would accept a RC with this situation >>> (or not). >>> >>> Anyway, I do agree that the current critical and blocker bugs are >>> important but should not stop the 2.1 release (especially if a 2.1.1 >>> release aferwards is much faster to do.) It would be cool to have >>> VFS-570 (write suport for VFS, but even that could be delivered with >>> 2.1.1 - it might annoy the HDFS folks a bit) >>> >>> So I can help you in case you need me to sponsor some changes (I hope I >>> have enough karma now). >>> >>> We could even make a joined RC1, I am just not sure it wont open a big >>> chunk of additional work. >>> >>> Gruss >>> Bernd >>> >>> Am Tue, 26 Apr 2016 09:40:01 -0400 >>> schrieb Josh Elser <els...@apache.org>: >>> >>>> Thanks Matt and Gary. >>>> >>>> I do recall seeing the asf-wide note that my commit-bit also applies >>>> to commons-*. Thanks for bringing that up. Specifically though, I am >>>> only interested in cutting a release -- if we can get a new release >>>> cut that we can use downstream, that increases the likelihood that I >>>> will have more things to contribute back :) >>>> >>>> I'll pull up the thread in the archives and get back to ya'll with >>>> any questions I have after that. >>>> >>>> - Josh >>>> >>>> Matt Sicker wrote: >>>>> It's from the thread called "Whatever happened to commons-io 2.5?" >>>>> A few people stepped up to give the necessary permissions and >>>>> committed his GPG key. >>>>> >>>>> On 25 April 2016 at 17:10, Gary Gregory<garydgreg...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Agreed, VFS 2.1 has been too long in the making. We can release >>>>>> ASAP without fixing more bugs IMO. RERO and all. >>>>>> >>>>>> As an Apache committer, your are also an Apache Commons committer, >>>>>> so feel free to create JIRAs, fix bugs and so on. >>>>>> >>>>>> There might be some karma issues with a non-PMC member performing a >>>>>> release, and I think we just went through this (sorry, I'm in >>>>>> settling in a new house, not much time to dig in the ML archives). >>>>>> >>>>>> Does anyone recall? >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> There are presently 171 resolved issues sitting in commons-vfs2 >>>>>>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like >>>>>>> blockers to >>>>>> me). >>>>>>> The lack of any release of commons-vfs2 in years has been a big >>>>>>> problem downstream. This past weekend, I was again annoyed by >>>>>>> bugs that have been fixed (but not release) which is spurring me >>>>>>> to take some action. There have been emails reaching back as far >>>>>>> as 2014 asking when the next >>>>>> release >>>>>>> might be, not to mention the fact that vfs-2.0 was released in >>>>>>> 2011 (!). >>>>>>> >>>>>>> History aside, I'm reaching out today to: >>>>>>> >>>>>>> 1) See if anyone on the PMC has the cycles to volunteer as RM. >>>>>>> 1a) If not, how can you empower me (or others) to make the >>>>>>> release on your behalf. >>>>>>> 2) Understand, specifically, what (if any) roadblocks exist to >>>>>>> release this version. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> - Josh >>>>>>> >>>>>>> >>>>>>> >>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> Java Persistence with Hibernate, Second Edition >>>>>> <http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action<http://www.manning.com/templier/> >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > 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
