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. >
Applogies Josh, I'm mixing me threads! Gary > > > 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
