On Sun, May 7, 2017 at 9:01 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> ...snip... > 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 > Sorry for the delay, been meaning to respond to this post for a while. Part of the problem I think is that the discussion is centered around only a portion of the potential problem space. The notion of versioning comes in here as dealing with only bc-breaking updates to an existing spec. However, another problem exists which you've seen the impact of today: Highly related packages that are actually different. Today you have PSR-6 and PSR-16 which are both cache specifications. Yet one is \Psr\Cache and the other is \Psr\SimpleCache. This results in a quite nuanced question: at what point does a change result in a semver bump, and at what point does it create a completely new namespace? You could take the approach of dealing with it one-off, and deciding on a case by case basis. But the two different approaches have radically different impacts on implementers. Semver requires the community to adopt the new version, basically in lockstep (as has been discussed in this thread). The new namespace approach gives a lot more flexibility for adoption at the cost of slightly higher maintenance burdon. However, let me ask this question: if an adapter can be trivially built to allow both versions to be run at the same time in the same codebase, why prevent that? For trivial changes like adding types to an interface, this is trivial to see (how it's easy to run both side by side). For major changes you're already doing this informally by naming the namespace after the package type. The case where "psr/log": "^1.0 || ^2.0" makes sense is only if the dependency can really be swapped out directly. Otherwise you're introducing a ton of complexity on each package to decide based on which version it was passed (think about if you add a method in 2.0, your logic must change if passed a 1.0). Depending on either only really makes sense if you're only using common functionality or the change isn't dependency-breaking (adding type signatures only affects implementers, not dependers). And those style changes are going to be fewer anyway since a lot of the discussion about existing standards is about changing them materially, not just implementation-details. So I ask, why not use one mechanism (which you're already using) and let it remove the headache from end users having to deal with "I can't upgrade package X because it's PSR-42 but my existing codebase depends on PSR-31". Anthony -- 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/CAAyV7nEQjFht3CAYvpfwHgtsO4Q4ooiF6GoGG0ECrN0psF4P0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
