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>
