Hi, On Tue, May 13, 2025 at 12:56 PM Tim Düsterhus <t...@bastelstu.be> wrote:
> Hi > > Am 2025-05-13 12:13, schrieb Jakub Zelenka: > >> From my experience in maintaining an old PHP application and > >> upgrading > >> it to support the latest and greatest PHP every year, I think the > >> following points would be a good starting point to discuss: > >> > >> - For backwards compatibility breaks introduced in minor versions > >> there > >> MUST be a simple (for some appropriate definition of simple) way to > >> adjust the code to be compatible with both the current PHP version and > >> the upcoming version. Ideally the change would be compatible with a > >> wider range of past PHP versions (past 3 or so?). It must be a change > >> that is simple to perform even with basic tooling (i.e. not requiring > >> an > >> IDE or static analyzers). > >> > > > > If I understand it correctly, this sounds really more like completely > > new > > rule that we don't currently have so I would rather not add it. We > > don't > > have this relation differences between X.Y and X.(Y+2) to do some extra > > breaks so it's more for a separate RFC. I'm also not a big fan of such > > change to be honest. > > We don't currently have any rules at all, except for “when the RFC > approves the break, then it's okay”. I was trying to find some guideline > for BC breaks that might be okay in a minor (when approved) and BC > breaks that are never okay in a minor. > What I meant is that this would be quite significant change as it could lead to some sort of bigger breaks when people could think that introducing break after few years is ok. That's how I understood it but thinking about it, it would be probably fine if it was an additional restriction (meaning we would still keep "Syntax backward compatibility SHOULD be preserved"). It would need some good formulation though. So if you can come up with something that is clear, I would be happy to add it. > The application in question is in a very similar position that PHP > itself is, it has a large public API that "third party" developers rely > on and a long development history. BC breaks sometimes are not avoidable > when you try to move forward. Basically the rule of thumb for a breaking > change in a minor version was that "most third party add-on should be > adaptable with minimal changes, while remaining compatible with both > minor versions after making these minimal changes". > I understand what you mean. The only challenge is to find a good wording to the policy. :) Kind regards Jakub
