commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [VFS] BC breaks in VFS 2.1 RC1
Date Fri, 06 May 2016 22:46:31 GMT
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

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