On Fri, May 6, 2016 at 10:20 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 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. > Well, yeah, RERO would have been great but it was not on high enough on my priority list too ;-) The issue we have now would have popped each time we wanted to break BC, so we could have gotten a better feel for it with RERO and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang release now. I would request another RC from the RM, and let the community decide by VOTE. Gary > > 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 > > -- 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
