I like Larry's reasoning about the problems that a 2.0 versioning would bring up.
But what about the reverse side? How could a package signal in it's deps that is compatible with one or the either version (or both)? Maybe we can discuss this at length this weekend @ PHPDay.. Il giorno lunedì 8 maggio 2017 03:01:32 UTC+2, Larry Garfield ha scritto: > > On 04/11/2017 03:19 PM, Larry Garfield wrote: > > Hello, peoples. In response to some recent off-list discussion (at > > conferences and elsewhere), I offer this brief survey about how we > > should namespace interface PSRs once we start producing "updated" > > versions (eg, PHP 7-ified versions) of existing specs. The survey > > itself has more details, and should take under a minute to complete. > > Please do so! > > > > > https://docs.google.com/forms/d/e/1FAIpQLSc8VJySoz_3koQThe057zYhzSkmOvOAgO0pEmenwr1Biu6JEA/viewform > > > > > > > This is a non-binding information gathering tool only to kick off a > > discussion, not to end one. Feel free to discuss more in this > > thread. I'll leave the survey open for 2 weeks or until people stop > > responding to it. :-) > > > > All are welcome and encouraged to respond, even if you're not a Core > > Committee member or Project Rep. > > > > --Larry Garfield > > A bit late (I've been a bit distracted, plus DrupalCon), but I've closed > the poll. The results are available here: > > > https://docs.google.com/forms/d/1XAi_RZW_Ang_N-QZEc0SU2DwmV-6n31elex2753d9QU/edit#responses > > > Items of note: > > * Only 5/12 members of the Core Committee participated. :-( > > * Only 7 project reps participated. :-( > > * Overall, there seemed to be a strong lean toward "no change", vis, a > hypothetical updated PSR-20 logger would live in the \Psr\Log namespace > and the psr/log Composer package, with a 2.0 tag. > > * That was far from a unanimous position, however. All other options > had their adherents, although \Psr\Log\V2 seemed to be generally disliked. > > The strong lean toward "stet", plus the discussion thread, makes me > think I did a poor job of explaining the problems with it. So, let me > try again: > > Consider PSR-3: > > interface LoggerInterface > { > public function emergency($message, array $context = array()); > public function alert($message, array $context = array()); > public function critical($message, array $context = array()); > public function error($message, array $context = array()); > public function warning($message, array $context = array()); > public function notice($message, array $context = array()); > public function info($message, array $context = array()); > public function debug($message, array $context = array()); > public function log($level, $message, array $context = array()); > } > > Now consider a hypothetical "PHP7-ify only" PSR-20: > > interface LoggerInterface > { > public function emergency(string $message, array $context = > array()) : void; > public function alert(string $message, array $context = array()) : > void; > public function critical(string $message, array $context = array()) > : void; > public function error(string $message, array $context = array()) : > void; > public function warning(string $message, array $context = array()) > : void; > public function notice(string $message, array $context = array()) : > void; > public function info(string $message, array $context = array()) : > void; > public function debug(string $message, array $context = array()) : > void; > public function log(string $level, string $message, array $context > = array()) : void; > } > > Off hand it seems like they should be easily compatible. However, > consider that most packages are likely to be referencing it like so in > composer.json: > > { > "require": { > "psr/log": "~1.0" > } > } > > That is, they are saying they're not compatible with psr/log 2.0. > > Now we release PSR-20 as psr/log 2.0 on Packagist. My Hare library > already requires PHP 7.3 (because I'm just that forward-looking) so I > can require it easily: > > { > "name": "crell/hare", > "require": { > "psr/log": "~2.0" > } > } > > Michael's Tortoise library, however, is more staid (by which I mean, > only minimally maintained), and so he hasn't updated his composer.json > file. It still says ~1.0. > > Now Sara comes along and tries to write an application that uses both > crell/hare and michaelc/tortoise, because both are solid libraries that > do useful things. Composer will, of course, not let her install both > the 1.0 and 2.0 versions of the same package, so it will simply error > out. crell/hare and micahelc/tortoise are now utterly incompatible with > each other, because they depend on different versions of an > otherwise-identical logging interface. Both would technically work fine > if run on a supported PHP version (that is, 7.1 and up), but the > versioning collision gets in the way. This makes Sara sad, and nobody > wants that. > > The simple answer is "well submit a PR to micahaelc/tortoise to update > his version requirement, since we know it works." However, that > introduces a new language version dependency on Tortoise which should be > treated as a major version bump. It also means that Tortoise is now > incompatible with philsturgeon/turtle, which is also using the 1.0 > logger. Hence Phil needs to update his Turtle at the same time. (That > sentence is begging to be OHed...) > > In short, it means that all 2494 PSR-3 using packages on packagist.org > (as of this writing) need to all release a new major version *at the > same time*. That's totally not going to happen. Or, someone needs to > develop a bridge library called LogPlug that abstracts away the > differences, which... rather defeats the whole purpose of having a PSR > interface. > > This seems like an undesirable situation, and one that would likely lead > to PSR-20 never being adopted by anyone simply for entirely artificial > chicken-and-egg reasons. (And really, you don't want artificial chicken > or eggs. They're kinda gross.) > > Now, for a trivial case like this where all that's happening is adding > scalar type hints, one could argue that a 1.1 version would suffice. > That's a reasonable argument. However, not all changes are so trivial. > For instance, we may also have cause to add another reserved keyword in > the $context array besides "exception". As a (small) API change that > would necessitate a 2.0 release either way. Or consider PSR-6, where any > update should, presumably, update the expiresAt() method to include a > proper type hint (as we can safely assume PHP 5.5+ now); however, that > would then mean the error handling changes from the errata I *just* > posted (and which is likely to pass based on previous discussion), and > thus also be nominally an API change. Certainly for the heightened > precision one would expect from a "standard" such minor changes should > be taken with caution. > > And all of that is assuming changes that are, in all but the strictest > sense, "mostly backward-compatible". Should any other changes be > appropriate for an updated version of a spec, the problem is far worse. > > Versioning the interface names would *not* solve all of the problems > presented above. It would, however, address *some* of them. > > Given that, I must disagree with the poll respondents who favored a "do > nothing" approach. I am not sure what alternative I favor at the > moment, but I do not feel the status quo is adequate. > > (Anthony Ferrara, please correct me if I explained the above wrong; > you're the one who brought it up to me originally.) > > --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/087143a1-19db-4b0a-b651-59c8cfa355f6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
