Hello everyone, I would like to push forward a proposal that is bugging me for so long. Today I read this comment on our GitHub: https://github.com/php-fig/fig-standards/pull/1171#issuecomment-499382349
Larry correctly shot down the last in a long list of small PRs that our approved PSRs had received in the past. This is because the PSRs, as standards, should be immutable, and they cannot be changed meaningfully, apart from small erratas. I would like to change that. This is a topic that many times surfaced in our chats, but we never tried to solve it. The release schedule of the language is a lot more tight and fast compared to the past, and we need to keep up the pace, to avoid that our PSRs become obsolete in a matter of years. My proposal is simple but limited; I didn't work on a full text change of our bylaws, but before I delve in the technicalities I would like to try and explain my idea succinctly, to see if I have some consensus about it. This is the summary of my proposal: - PSRs packages can receive new major releases - new majors should be used just to improve the code, so that it can use new language features (types, return type, void, \Throwable...) - the new major should never break the spec - implementors should be able to easily support all majors of the package (AKA "psr/*": "^1.0|^2.0"); even more, it should be recommended - if possible, the additions to the spec should just be added to implement in code something from the spec that before wasn't expressible before (like exceptions interfaces extending `\Throwable`) - a changelog should be appended to the PSR to reflect the changes in the new version - the process to make this happen should be: -- PR to the PSR -- demonstrate straightforward cross-compat between version -- editor approval, calls a CC vote -- CC vote with 2/3 majority What do you think? Do you think this is doable? -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/89341907-fca6-448a-a887-531d0f7b6a89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
