One idea is to categorize the root Psr namespace by PHP version. For example, the recommendations for PHP 5 and, for example, PHP 7.2 is different, so we could do it this way; Psr\Log for PHP 7.0 and below (for backwards compatibility), and Psr71\Log for the revision that takes advantage of PHP 7.1 language features. If, in the future, let’s say PHP 7.5, they add an amazing feature that changes everything (*cough*generics*cough*), we could then have Psr75\Log.
Not sure if this is a good idea, but just throwing it out there. John On Apr 14, 2017, at 4:53 AM, Michael Mayer <mich...@schnittstabil.de<mailto:mich...@schnittstabil.de>> wrote: 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<mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com<mailto: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<https://groups.google.com/d/msgid/php-fig/78ebeeef-e62a-4e57-85c9-74eea6276d3e%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- 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/4A311C3A-CC75-4209-9DFC-9EF3439330C2%40buffalo.edu. For more options, visit https://groups.google.com/d/optout.
