On Fri, Oct 11, 2024 at 3:34 AM Rob Landers <rob@bottled.codes> wrote:
> On Fri, Oct 11, 2024, at 12:20, Jonathan Vollebregt wrote: > > > A "proper" implementation won't break, but there may be subtle ways that > "improper" implementations will break and thus it should be considered a BC > break. > > This thread is fallaciously equating breaks in third-party libraries > _when changing consumer code_, with breaks just by updating PHP. > > If I'm in PHP 8.1+ and I pass an object into a library and all goes > well, then I change a property to readonly and get an error, that's not > PHP making a breaking change by allowing me to use readonly. That's an > outdated library (and me) breaking my code. > > I've had my reflection code break on backwards compatible changes loads > of times, but every time it required the user to make a change to their > code first. > > Valentin's list of examples proves this point. They worked fine on 8.1 > _until_ people changed code to add readonly. That's not a BC break. Same > deal for aviz. > > > I guess what I am saying is that we probably need a proper definition of > "BC break". IMHO, adding a php version check to do something is probably a > BC break. Serializers will need a version check, thus it is a BC break. > > — Rob > Is this not something than has a really standard and consistent definition? "Code which runs correctly on the previous version of the project, if it is not updated, will also run correctly and provide the same output on the next version." Backwards compatible has never, in any work I've done through my entire career, meant something like "if you take old code and then update it to the new version incorrectly, it doesn't work"... that seems... obvious? What exactly is the claim being made here? Because it sounds like the claim is very much that second "definition". Jordan
