Following the rules of the workflow bylaw, once a PSR has been “Accepted” the PSR meaning cannot change, backwards compatibility must remain at 100%, and any confusion that arises from original wording can be clarified through errata.
The rules for errata are covered in the workflow bylaw, and only allow non-backwards compatible clarification to be added to the meta document. Sometimes, modifications will be necessary in PSR document itself, and this document outlines those cases.
The question here is what exactly is implied by "backwards compatibility".
In the usual sense of "backwards compatibility" with regards to a class, for example, the addition of a new feature (such as a new method or optional argument) maintains "backwards compatibility", in the sense that it doesn't change something that already exists.
In the same sense, the omission of this important detail in the specification doesn't change something that already exists, but rather adds something that was missing and thereby addresses a problem with the existing specification.
While this will render some existing implementations "buggy", these were already "buggy", in the sense that they can't actually be used with existing emitters or with predictable results, as per the circumstances described in proposed section 5.7 of PSR-17-http-factory-meta.md.
mindplay-dk
commented
5 years ago
I am proposing the following amendment to PSR-17.
I am aware of the amendments clause of the bylaws:
The question here is what exactly is implied by "backwards compatibility".
In the usual sense of "backwards compatibility" with regards to a class, for example, the addition of a new feature (such as a new method or optional argument) maintains "backwards compatibility", in the sense that it doesn't change something that already exists.
In the same sense, the omission of this important detail in the specification doesn't change something that already exists, but rather adds something that was missing and thereby addresses a problem with the existing specification.
While this will render some existing implementations "buggy", these were already "buggy", in the sense that they can't actually be used with existing emitters or with predictable results, as per the circumstances described in proposed section 5.7 of
PSR-17-http-factory-meta.md.The issue was debated on the forum here:
https://groups.google.com/forum/#!topic/php-fig/S5YIw-Pu1yM