Why laravel Ecosystem does not consider new method as a breaking change?

[AlShahawi]

As the title says, but I will try to explain clearly.

For example, Let's imagine that the current version of Laravel is 7.0.0 and it has the following class:

<?php

namespace Illuminate\X;

class A {}

And we are using the framework for developing our application and we have decided to extend the functionality of class A by inheriting from it.

<?php

namespace App;

class ExtendedA extends \Illuminate\X\A
{
    public function doSomething() { /* functionality of something we want */ }
}

If Laravel introduced a new method (eg. a new feature) such as (doSomething($differentSignature)) for class A it considers this as a minor release 7.1.0?

I know since Laravel version 6.0.0 its releases will be semantic version-ed and regarding Semantic Versioning schema, this change is not backward compatible.

Note:
I have found Backward Compatability Promise for Symfony as it defines what will be guaranteed to be backward compatible and what is not, and they mentioned that adding a new method for a subclass will not be guaranteed to be backward compatible for next minor released. Why Laravel do not have a clarification like that?

[browner12]

Can you provide examples of PRs that show this?

[AlShahawi]

Take the following pull requests as an example

1. [7.x] Add toPsrRequest method in Http Client Request #33016
2. [7.x] File::guessedExtension() method #33001

[driesvints]

These are perfectly valid examples of code that can be tagged as a minor release.

[AlShahawi]

These are perfectly valid examples of code that can be tagged as a minor release.

But it is not backward compatible, that's the case I am talking about what if someone added those methods (in the pull request) with a different signature before this release?

I don't have a problem if Laravel doesn't consider this as a breaking change, but it will be much better to clarify these things as Symfony did.

[driesvints]

It is perfectly backwards compatible for the public api of the framework. Userland code is not part of the public api of the framework.

[driesvints]

https://semver.org/#spec-item-7

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

[driesvints]

I know since Laravel version 6.0.0 its releases will be semantic version-ed and regarding Semantic Versioning schema, this change is not backward compatible.

It is. We can't account for you extending the class and adding methods of your own. Those don't belong to the public API of the framework. Extending and overwriting classes if on your own risk.

[AlShahawi]

I have no problem with that. I think it will be much better if we have something like what Symfony has and call it Backward Compatability Promise

[driesvints]

We already state that we use SemVer here: https://laravel.com/docs/7.x/releases#versioning-scheme. That's enough imo.

[devcircus]

Even the Symfony and Cake documentation states that they can't account for method name collisions with userland code when adding new methods to their framework.

However, backward compatibility comes in many different flavors. In fact, almost every change that we make to the framework can potentially break an application. For example, if we add a new method to a class, this will break an application which extended this class and added the same method, but with a different method signature.

They note that if you add a method to a class that you are extending from Symfony, they can't promise no bc breaks:

Add a new method: NO

[AlShahawi]

@devcircus Yes, I think IMO that we need this kind of clarification for Laravel it will be better than nothing.