Ray - I assume that you’re asking why this is a MINOR change, rather than a MICRO change? It’s obviously not a major change because the method exists with the same signature everywhere both before and after.
The reason that it’s a MINOR change is to do with the forward (rather than backward) guarantees that the semantic versioning rules must make. In your example you end up deleting the original doFoo() implementation from the Bar class. From this point on the Bar class has no knowledge of this method, and the implementation *must* come from either a super type (there aren’t any) or as a default method on the implemented interface. If this doesn’t happen then the whole type hierarchy of Bar is broken - the concrete types which subclass Bar simply don’t have an implementation of the interface method that the contract says they must have! The only way to enforce this is to ensure that the updated Bar class imports a version of Foo which is guaranteed to have the “default doFoo() feature”. In semantic versioning new features always require at least a MINOR bump so that people can reliably depend on them (depending on a MICRO is not a good idea). That is what is happening here. Tim PS - I have just seen Peter’s email come in, which thankfully agrees with what I’m saying! > On 5 Dec 2017, at 06:43, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > Hi, > > IMHO it is a MINOR change because it is not a breaking change. J > > With that change neither implementations of the Foo interface, nor classes > that extend the abstract Bar class will break. > > Implementations of the Foo interface can still implement the doFoo() method > and by doing this override the default behavior. Overriding a default is not > a breaking change as you neither add a new public method or field, you just > give a default implementation. > > Classes that extend Bar did not need to implement doFoo() before, as it was > implemented in Bar. Removing that method would be typically a breaking > change. But you are moving it as default method to the Foo interface. > Therefore Bar still has the doFoo() method implemented, as it is provided by > the Foo interface. > > I have to admit that I am not 100% sure about the byte code in the end and if > that matters. But as a user of the interface and abstract class, nothing > breaks. > > Mit freundlichen Grüßen / Best regards > > Dirk Fauth > > Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) > Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | > www.bosch.com <http://www.bosch.com/> > Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com > <mailto:dirk.fa...@de.bosch.com> > > Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; > Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar > Denner, > Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. > Markus Heyn, Dr. Dirk Hoheisel, > Christoph Kübel, Uwe Raschke, Peter Tyroller > > > Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] > Im Auftrag von Raymond Auge via osgi-dev > Gesendet: Dienstag, 5. Dezember 2017 00:26 > An: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Betreff: [osgi-dev] making an existing interface method default causes MINOR > baseline change > > Hey All, > > I think the answer is "Yes it's a MINOR change", but I wanted to clarify. > > Assume I have the following interface in an exported package: > > public interface Foo { > public void doFoo(); > } > > And in the same package I have abstract class Bar which implements Foo: > > public abstract class Bar implements Foo { > public void doFoo() {...} > public abstract void doBar(); > } > > And I want to migrate to a default method because doFoo() logic rarely > changes: > > public interface Foo { > public default void doFoo() {...} > } > > public abstract class Bar implements Foo { > //public void doFoo() {...} > public abstract void doBar(); > } > > Can someone explain why this is a MINOR change? > > > -- > Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) > Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
