After reconsidering my second last post, I must admit that 1. non-BCs, like adding methods etc.
is wrong. Adding methods to a PSR interface might not break code of consumers, but clearly breaks code of implementation providers. Interestingly, this shows that SemVer does not work well for PSR packages. Usually we have a one-to-many relationship between implementation providers and consumers; and a minor version bump just signals new features – no problem for legacy consumers. But PSR-Packages are contracts for many implementation providers, thus a new minor version bump is always a breaking change for them. Anyway, I still believe we should focus on *unquestionable* breaking changes first. On Thursday, April 13, 2017 at 5:35:30 PM UTC+2, Michael Mayer wrote: > > Aw, sorry. BC := breaking change > > On Thursday, April 13, 2017 at 5:33:39 PM UTC+2, Daniel Hunsaker wrote: >> >> On Thursday, April 13, 2017 at 8:55:25 AM UTC-6, Michael Mayer wrote: >>> >>> We should distinguish 3 cases: >>> >>> 1. non-BCs, like adding methods etc. >>> 2. BCs for some PHP versions, like adding parameter type declarations >>> 3. BCs for all PHP versions, like adding return type declarations >>> >>> It would be advisable to focus on case 3. first – the other cases may >>> depend on the outcome of it. >>> >> >> Trying to ensure I understand you - by BC here, do you mean >> "backwards-compatible changes" (as the abbreviation normally indicates), or >> "backwards compatibility breaks"? >> > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/78ebeeef-e62a-4e57-85c9-74eea6276d3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
