That was me. I have had those thoughts and mentioned them a few times since Java 7 was released. But absolutely no effort has been expended to do it.
My personal opinion is that I am comfortable with releasing 2.1 with the issues Gary mentions. There should have been 10 releases for VFS 2 by now. Ralph > On May 6, 2016, at 8:40 PM, Matt Sicker <boa...@gmail.com> wrote: > > I thought there were talks about using Java 1.7 APIs in 3.0 that would > eliminate the need for some classes in commons-vfs, or am I confusing that > with another commons project? > > On 6 May 2016 at 17:46, Gary Gregory <garydgreg...@gmail.com> wrote: > >> OK, I've gone through the Clirr report and fixed the low-hanging fruits in >> trunk. I think we need another RC. I've also update Apache Commons Compress >> and Net to their current versions. >> >> Then what we have to live with for 2.1 is BC breaks in two narrower areas: >> >> - Added methods to interfaces. >> - Changes in the Tar classes from our own Tar classes to Apache Commons >> Compress' Tar classes. >> >> That's how good it's going to get for now IMO. >> >> I would be perfectly OK with repackaging for 3.0 but then this would open >> the door to other changes that folks might want to make. I would be OK with >> saying this is 3.0 as is in this case. >> >> I'm still not 100% comfortable with the BC based on my experience with >> large projects with deep transitive dependencies. >> >> If the community VOTEs to release trunk (yes, another RC please) as 2.1 >> then I'll live with it. Releasing as 3.0 (as is) would be safe and >> conservative. >> >> Gary >> >> On Fri, May 6, 2016 at 3:00 PM, sebb <seb...@gmail.com> wrote: >> >>> On 6 May 2016 at 22:40, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> I'm creating a new thread here instead of hijacking the VOTE thread. >>>> >>>> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a >>>> release, I'm sure he did not know what he was getting himself into! ;-) >>> >>> Huh? ... that was/is Josh Elser. >>> Who does (also) deserve many thanks. >>> >>>> Part of me writing this here is flushing out for myself, voters, and >>> casual >>>> observers what it is we are doing ;-) >>>> >>>> We have BC breakage in VFS 2.1 RC1 in two areas: >>>> >>>> - Adding methods to public interfaces >>> >>> AFAIK that is only a SOURCE breakage. >>> >>>> - Other stuff like removing fields, changing fields from protected to >>>> private, changing method arg types. >>> >>> That does break BC if the objects are part of the public API. >>> >>>> Details: >>>> >>> >> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html >>>> >>>> I see three areas that need consideration: >>>> >>>> (0) For simple clients that only use the higher-level interfaces and >>>> methods, there are no problems. So this is a non-issue marker I >> suppose. >>> >>> Whether or not that affects simple clients depends on exactly which >>> fields and method args have changed. Are they part of the public API? >>> And if so, will simple clients use that part of the API? >>> >>>> (1) For advanced clients that get their fingers in deep into VFS, they >>>> break. Example: >>>> >>>> - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of >>>> field entry has been weakened from protected to private. >>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed >>> field >>>> AUTHENTICATOR_TYPES >>>> - and so on. >>>> >>>> Remedies for these kinds of breaks are simple and easy: Just change >> stuff >>>> back and mark @deprecated in Javadoc and @Deprecated. >>>> >>>> (2) For providers, they break unless they extend our root classes like >>>> AbstractFileObject and DefaultFileSystemManager, and use our default >>>> classes like DefaultFileContent. >>>> For "simple" providers, there probably won't be any issue, but who >> knows? >>>> Does anyone have a 2.0 provider? >>>> For advanced providers that do more of their own thing instead of >> reusing >>>> our base classes, then breakage. >>>> >>>> It seems to me that we should pick the low-hanging fruits and fix the >>>> simple stuff. >>>> >>>> All of this is moot if we were to go to 3.0 now. >>> >>> Which would not be source or binary compatible by design. >>> >>>> Thoughts? >>> >>> The easiest for Commons would obviously be to abandon 2.x and release >> 3.0. >>> That would be a chance to fix APIs properly. >>> >>> However, given the work that Josh has already put into 2.1 that seems >>> a waste of effort if we can either: >>> - eliminate the BC breaks, OR >>> - satisfy ourselves that the breaks will not affect (m)any users. >>> >>>> Gary >>>> -- >>>> 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 >>> >>> >> >> >> -- >> 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 >> > > > > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
