Great minds think alike (and it helped we were both in this discussion) :-)
P > On 5 Dec 2017, at 09:03, Timothy Ward via osgi-dev <[email protected]> > wrote: > > 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 >> <[email protected] <mailto:[email protected]>> 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 | [email protected] >> <mailto:[email protected]> >> >> 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: [email protected] <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] Im Auftrag von Raymond Auge via >> osgi-dev >> Gesendet: Dienstag, 5. Dezember 2017 00:26 >> An: OSGi Developer Mail List <[email protected] >> <mailto:[email protected]>> >> 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 >> [email protected] <mailto:[email protected]> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
