On 16 July 2012 21:31, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > With the addition of many new methods to the FileObject interface and other > TAR changes reported by Clirr [1], the next release will break BC for VFS > providers (those not provided by VFS itself.) > > For normal call sites of the interfaces, nothing should change. For call > sites that use the TAR provider classe, some VFS TAR changes might need > call site changes. > > Therefore, strictly speaking, the next release should be 3.0 with a package > rename. > > Thoughts?
If it is only the TAR classes that break BC, could these alone be renamed? If so, the original classes could be kept and deprecated. As a separate issue, if BC does have to be broken in some or all of the code, then please consider privatising all mutable variables (use setters/getters) and reducing visibility of classes and methods that are not intended to be part of the public API. I've not looked at the code, but it also strikes me that it might be possible to maintain BC by keeping and deprecating the methods that have changed parameter types; introducing a new interface for the new methods, and creating new methods for createTarFile and getTarFile which have changed return types. > [1] http://oi46.tinypic.com/2ef46qr.jpg > > Thank you, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > 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
