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 Sat, 07 May 2016 05:29:08 GMT
On Fri, May 6, 2016 at 10:20 PM, Ralph Goers <ralph.goers@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 <boards@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 <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>
>
>
>
> ---------------------------------------------------------------------
> 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