Magento 2. Technical Guidelines. Module Version Dependency Question

Question

I am looking at the official docs here

Why is it that when changing the preference of a class marked with @api you can depend on a MAJOR version but when you change the preference of an interface marked with @api you have to depend on a MINOR version release. Is it not kinda the same thing?

Same thing goes for implementing an interface (depend on MINOR) and extending a concrete class (depend on MAJOR) both marked with @api

What is the reasoning behind this?

IMHO implementing an interface should not make me more dependent on a module than extending a concrete class.

Answer 1

I'm leaving here a possible answer, more of an assumption.

Regarding the preference issue the assumption is that the rewrite class is extending the original class, so if a method is added to the original class the rewrite will inherit it. As for the preference of an interface, if a method is added to the interface, the code will break.

To the other one implementing and interface vs extending a class the same principle applies, if a method is added to the interface the code will break, but if adding a method is added to the parent class the method will be inherited and the code will not break.

This however does not apply to case in which a method is added to the concrete class and there already exists such a method in the child class with a different signature. Or if in the parent class an abstract method is added.

Answer 2

I also read the same technical documentation while ago and came to the same conclusion. On the surface it doesn't make sense.

A year or so later and I'm still confused by it.

My best guess is someone at Magento was trying to preemptively predict that certain areas were going to undergo a significant change.

Personally I've rarely coded something that depends on a certain version. And if I face incompatibility I create a different version of the file(s) to work with that particular version. Model21.php, Model22.php, Model23.php etc Wyomind take similar approach. It's a bit untidy but gets the job done. Plus your code is still readable. Just means you need someone with a bit of knowledge to install extension especially if you bundle all the files together.

But I'll admit I haven't produced anything too revolutionary. I generally try to work within the realms of the framework.