commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: [VFS] BC breaks in VFS 2.1 RC1
Date Sat, 07 May 2016 03:40:57 GMT
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 <garydgregory@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 <sebbaz@gmail.com> wrote:
>
> > On 6 May 2016 at 22:40, Gary Gregory <garydgregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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 <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message