On Thu, Jun 6, 2019, at 11:16 AM, Alessandro Lai wrote: > 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?
There's been discussion of "point release PSRs" in the past, which is similar but perhaps a bit larger in scope. My main concern is this point: > - 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 The scope of possible changes that wouldn't "break the spec" is exceedingly small. There are numerous changes that would not break the semantics of the spec, but would break the strict "composer update and ignore" compatibility of the spec. Remember, much of what we release is interfaces, and changing an interface even slightly can have huge knock-on effects. As a few examples: * Adding the `object` type hint to PSR-14's Dispatcher::dispatch() return. This was left out to ease BC, and anyone not returning the event there is Wrong(tm). However, adding that type hint later in a few years would break any existing implementation because they don't have a return type specified and thus it would be type widening a return. So that's a spec change. * PSR-6 didn't include a DateTimeInterface parameter on one method, for PHP 5.4 compatibility. That caused a bug where it was unclear how to handle error conditions, leading to an errata that took two tries to get through. If we were to now add the parameter hint, that would break PHP 7.0-based implementations that don't support type widening on parameters. (That came in later versions.) It also changes the behavior in an error condition, as it would now throw TypeError rather than whatever the errata recommended (which was a different exception, I think). So that's a spec change. * PSR-7 would greatly benefit from adding return types to its methods, as has been discussed before. However, for the same reason as the first example that would not change the semantics, but would break all existing implementations. So while I am open to improved ways for specs to "keep up withe times" without being redesigned, in practice I don't think 100% transparent changes are really possible outside of a few very very specific cases like the "CustomException extends \Traversable" example. --Larry Garfield -- 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/fe1d989e-0838-48e1-9ef6-6901ca40f7f0%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
