Survey: Naming things

[Larry Garfield]

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

[Michael Mayer]

Compatibility ftw!

Hence, a new namespace and a new composer package – I do not care about the concrete new names though:

namespace Psr\Log;

interface LoggerInterface
{
    public function alert($message, array $context = array());
}

namespace Psr\Log\V2;

interface LoggerInterface
{
    public function alert(string $message, array $context = array()):void;
}

class Logger implements \Psr\Log\LoggerInterface, \Psr\Log\V2\LoggerInterface
{
    public function alert($message, array $context = array()):void
    {
        // …
        return;
    }
}

Bests,

Michael Mayer

[Stefano Torresi]

Hey Michael,

That would trigger a fatal error because the signatures are not compatible.

[Woody Gilk]

I've taken the survey. Been thinking about this for several days and I think this is just pointing at a deeper issue with PSR numbering. Bottom line is, the numbering of PSRs has always been broken:

- sequential numbering is not semver

- numbers are assigned before acceptance, leaving gaps

- the only number anyone cares about is the composer version

- numbers are noise and always have been

I realize that FIG has taken the IETF approach, but I just don't think it works for when you try to apply it to code. Regardless of whether or not adding type hints to (eg) PSR-3 requires an entirely new PSR, the package/namespaces shouldn't be any different, it should just be a major version change in the composer package.

Pushing the PSR numbering into code is counter productive and confusing.

--
Woody Gilk
http://about.me/shadowhand

--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 php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1a010cb1-a7fa-286a-ac7d-d932177a26d5%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

[Rivera, John]

I agree wholeheartedly with Woody Gilk.

FWIW, from a non-member :)

John

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6JvcPSy_SJjqP6RGnMc1mOzrQUbdSynPTB93%2BM8Fhau-A%40mail.gmail.com.

[Alexander Makarov]

Agree.

In case of PSR deprecation old version is replaced by new one so it makes sense to:

1. Use SemVer

2. In the README.md refer to PSR number interface is for

As for PSR-s themselves, I think sequential numbering is fine so IETF for standards, SemVer for code.

On Wednesday, April 12, 2017 at 1:09:17 AM UTC+3, Woody Gilk wrote:

I've taken the survey. Been thinking about this for several days and I think this is just pointing at a deeper issue with PSR numbering. Bottom line is, the numbering of PSRs has always been broken:

- sequential numbering is not semver

- numbers are assigned before acceptance, leaving gaps

- the only number anyone cares about is the composer version

- numbers are noise and always have been

I realize that FIG has taken the IETF approach, but I just don't think it works for when you try to apply it to code. Regardless of whether or not adding type hints to (eg) PSR-3 requires an entirely new PSR, the package/namespaces shouldn't be any different, it should just be a major version change in the composer package.

Pushing the PSR numbering into code is counter productive and confusing.

--
Woody Gilk
http://about.me/shadowhand

On Tue, Apr 11, 2017 at 3:19 PM, Larry Garfield <la...@garfieldtech.com> 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

--
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+u...@googlegroups.com.

[Adrien Crivelli]

Couldn't agree more with Woody Gilk.

PSR numbering may, or may not, be a nice things to organize the process, but it should not intrude into code. Code should be upgraded using semver major versions, as is expected for all composer packages.

[Igor Rinkovec]

Agreeing with Woody.

The implementation of the PSR should be treated as any other composer package, therefor using semver. This practice is familiar with all developers without needing to know any details about the PSR process. The PSR numbering should stay internal just for the ease of discussion inside the PHP-FIG community.

On 12 Apr 2017, at 04:44, Adrien Crivelli <adrien....@gmail.com> wrote:

Couldn't agree more with Woody Gilk.

PSR numbering may, or may not, be a nice things to organize the process, but it should not intrude into code. Code should be upgraded using semver major versions, as is expected for all composer packages.

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1e576ddf-91fb-40c4-8111-90915eb67157%40googlegroups.com.

[Michael Mayer]

The signatures will be compatible in PHP >= 7.2, because of PHP RFC: Parameter Type Widening – many thanks to Niklas, btw.

It's a new standard, thus it should have its own namespace and package – otherwise one will never be able use both PSRs within one project.

[Jordi Boggiano]

Same here. Especially as the way I see it, PSR v2's will really mostly
be a thing as the library ecosystem transitions to PHP7, because of the
added scalar hints.

Sure it will take some time for everything to migrate over, and it might
lead to small periods of incompatibilities/dependency resolution
conflicts along the way. Once we are through though we will be in a much
more desirable outcome than if we have \V2 namespaces or whatever other
similar hack.

Best,
Jordi

--
Jordi Boggiano
@seldaek - http://seld.be

[Alessandro Pellizzari]

On 11/04/17 22:01, Michael Mayer wrote:

> Compatibility ftw!
>
> Hence, a new namespace and a new composer package – I do not care about
> the concrete new names though:

> ...
> namespace Psr\Log\V2;

I agree, except for the namespace.

I think every PSR should have its own (2nd-level) namespace, and not
depend on others, so I would prefer

namespace Psr\Log2; // or Log7 or LogNew or TypedLog. You get the idea.

Having a semver major version change would mean we can't use the new
LoggerInterface if we already included a dependency using the old
LoggerInterface.

Having a sub-namespace could be confusing and the changes could be more
than just adding types, so the new PSR should be just lightly related to
the old one.

Bye.

[Michael Mayer]

On Wednesday, April 12, 2017 at 1:18:48 PM UTC+2, Jordi Boggiano wrote:

Same here. Especially as the way I see it, PSR v2's will really mostly
be a thing as the library ecosystem transitions to PHP7, because of the
added scalar hints.

The benefit of migration because of scalar type declarations is extremely minor, especially in an established TDD process.

 

Sure it will take some time for everything to migrate over, and it might
lead to small periods of incompatibilities/dependency resolution
conflicts along the way.

fool/echolog, for example, still requires psr/log:1.0.0 (not ~1.0 or similar!), which makes it unusable at the moment.

There is a PR, which is older than a half year. Well, that can be considered as a bug, but it is still not fixed.

But, what amount of time are we talking about? If we consider PSR-7, then we have more than thousand packages (solely at packagist!) which dependent on it.

Doing a BC by adding scalar type declarations (and doing a major version bump) will bring us years of dependency hell.

PSR interfaces are not ordinary packages. Those interfaces were created to accomplish compatibility between projects, therefore a BC is a no go.

Once we are through though we will be in a much
more desirable outcome than if we have \V2 namespaces or whatever other
similar hack.

 

Indeed, V2 is really bad.

[Jordi Boggiano]

Then maybe we have to ask ourselves.. Is it worth all the trouble just
to add a few type hints?

Maybe it's best to delay any such changes until PHP 7.2 is out, and then
new PSR versions could be released like psr/log 1.1.0 could be released
that requires PHP 7.2, and adds type hints.

As it seems 7.2 allows interface widening any library requiring PHP 7.2+
could start requiring psr/log ^1.1 and implement the interfaces with the
type hints, while other libraries requiring ^1.0.0 would remain
compatible with 1.1.0. That way if you require any library that require
1.1 then you have to upgrade but you need to run at least PHP 7.2.

Best,
Jordi

On 2017-04-12 13:57 PM, Michael Mayer wrote:
> On Wednesday, April 12, 2017 at 1:18:48 PM UTC+2, Jordi Boggiano wrote:
>
> Same here. Especially as the way I see it, PSR v2's will really mostly
> be a thing as the library ecosystem transitions to PHP7, because of the
> added scalar hints.
>
>
> The benefit of migration because of scalar type declarations is
> extremely minor, especially in an established TDD process.
>
>
> Sure it will take some time for everything to migrate over, and it
> might
> lead to small periods of incompatibilities/dependency resolution
> conflicts along the way.
>
>

> fool/echolog <https://packagist.org/packages/fool/echolog>, for example,

> still requires psr/log:1.0.0 (not ~1.0 or similar!), which makes it
> unusable at the moment.
> There is a PR

> <https://bitbucket.org/fool/echolog/pull-requests/2/expanded-psr-log-compatibility/diff>,

> which is older than a half year. Well, that can be considered as a bug,
> but it is still not fixed.
>
> But, what amount of time are we talking about? If we consider PSR-7,
> then we have more than thousand packages (solely at packagist!) which
> dependent on it.
> Doing a BC by adding scalar type declarations (and doing a major version
> bump) will bring us years of dependency hell.
>
> PSR interfaces are not ordinary packages. Those interfaces were created
> to accomplish compatibility between projects, therefore a BC is a no go.
>
> Once we are through though we will be in a much
> more desirable outcome than if we have \V2 namespaces or whatever other
> similar hack.
>
>
> Indeed, V2 is really bad.
>

> --
> 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+u...@googlegroups.com

> <mailto:php-fig+u...@googlegroups.com>.

> To post to this group, send email to php...@googlegroups.com

> <mailto:php...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

[Oscar Otero]

My opinion (from a not member) is PSR numbers for standars, semver for packages.

This is not only about type hints, that could be solved using some of the techniques described. It’s about defining a standard way to upgrade a package adding breaking changes replacing other standard.

Let’s say, for example, that PSR-7 is replaced by PSR-33. The new version adds types to the interfaces, but also adds attribute methods to response (withAttribute, getAttribute). This change affects also to other related standards using PSR-7 like PSR-15 middlewares and PSR-17 factories. So, they should be upgraded to PSR-34 and PSR-35, in order to handle this new version of http messages.

Having a project mixing all these old and new PSR is a bad idea. A middleware accepting PSR-7 and PSR-33? and creating a response using PSR-15 or PSR-34? I think mixing old deprecated versions and new versions should be avoided, and the way to do this is using semver. If you want to use the new PSR-33 http messages, make sure that all of your dependencies are upgraded to use these new version, otherwise, keep using PSR-7.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/083df612-8305-9205-0ef5-a85ab07e51f7%40seld.be.

[Michael Mayer]

We should distinguish 3 cases:

1. non-BCs, like adding methods etc.
2. BCs for some PHP versions, like adding parameter type declarations
3. BCs for all PHP versions, like adding return type declarations

It would be advisable to focus on case 3. first – the other cases may depend on the outcome of it.

On Thursday, April 13, 2017 at 12:35:12 PM UTC+2, Oscar Otero wrote:

If you want to use the new PSR-33 http messages, make sure that all of your dependencies are upgraded to use these new version, otherwise, keep using PSR-7.

This presupposes, that it is possible to upgrade all dependencies, which is often not the case. Sometimes it is not practicable because of the amount of packages, sometimes it is not possible because of licensing issues (closed source etc.).

IMO, it should be possible to migrate softly to a new PSR – FIG stands for Framework Interoperability Group and it would be a shame, if the FIG cannot achieve interop of their very own Standards Recommendations. From Wikipedia:

Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, in either implementation or access, without any restrictions.

"present or future" is crucial – a BC in conjunction with a major version bump prevents interop of present and future implementations.

[Daniel Hunsaker]

On Thursday, April 13, 2017 at 8:55:25 AM UTC-6, Michael Mayer wrote:

We should distinguish 3 cases:

1. non-BCs, like adding methods etc.
2. BCs for some PHP versions, like adding parameter type declarations
3. BCs for all PHP versions, like adding return type declarations

It would be advisable to focus on case 3. first – the other cases may depend on the outcome of it.

Trying to ensure I understand you - by BC here, do you mean "backwards-compatible changes" (as the abbreviation normally indicates), or "backwards compatibility breaks"?

[Michael Mayer]

Aw, sorry. BC := breaking change

[Michael Mayer]

After reconsidering my second last post, I must admit that

1. non-BCs, like adding methods etc.

is wrong. Adding methods to a PSR interface might not break code of consumers, but clearly breaks code of implementation providers.

Interestingly, this shows that SemVer does not work well for PSR packages. Usually we have a one-to-many relationship between implementation providers and consumers; and a minor version bump just signals new features – no problem for legacy consumers. But PSR-Packages are contracts for many implementation providers, thus a new minor version bump is always a breaking change for them.

Anyway, I still believe we should focus on unquestionable breaking changes first.

[Rivera, John]

One idea is to categorize the root Psr namespace by PHP version. For example, the recommendations for PHP 5 and, for example, PHP 7.2 is different, so we could do it this way; Psr\Log for PHP 7.0 and below (for backwards compatibility), and Psr71\Log for the revision that takes advantage of PHP 7.1 language features. If, in the future, let’s say PHP 7.5, they add an amazing feature that changes everything (*cough*generics*cough*), we could then have Psr75\Log.

Not sure if this is a good idea, but just throwing it out there.

John

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/78ebeeef-e62a-4e57-85c9-74eea6276d3e%40googlegroups.com.

[Adrien Crivelli]

Psr71\Log for the revision that takes advantage of PHP 7.1 

If we really need to use number in the namespace, then let's not introduce yet another number with PHP versions, but stick to PSR number themselves. so \Psr\Psr20\LoggerInterface, as one of the options suggested in the survey. I think it is more straightforward than an arbitrary project versions, such as \Psr\Log\V2\LoggerInterface or an unusual PHP version such as \Psr71\LoggerInterface.

[Rivera, John]

This does not solve the biggest issue with the best option (staying with the same namespace): projects cannot use two versions of the same interfaces during a migration. So your suggestion doesn't work. My suggestion would, as the namespace would be different between interface revisions arising from emerging language features.

On Apr 14, 2017, at 11:21 PM, Adrien Crivelli <adrien....@gmail.com> wrote:

Psr71\Log for the revision that takes advantage of PHP 7.1 

If we really need to use number in the namespace, then let's not introduce yet another number with PHP versions, but stick to PSR number themselves. so \Psr\Psr20\LoggerInterface, as one of the options suggested in the survey. I think it is more straightforward than an arbitrary project versions, such as \Psr\Log\V2\LoggerInterface or an unusual PHP version such as \Psr71\LoggerInterface.

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CACjDtnLLLqz1OxZwKRoO%2B-N-8q%3DdrsVWMeTOqwyrLawbNLBhbA%40mail.gmail.com.

[Andreas Heigl]

[…]

I realize that FIG has taken the IETF approach, but I just don't think it works for when you try to apply it to code. Regardless of whether or not adding type hints to (eg) PSR-3 requires an entirely new PSR, the package/namespaces shouldn't be any different, it should just be a major version change in the composer package.

Just for the record: IETF has two naming schemes: A sequential one for the RFCs and a different sequential one for the Internet Standards. The whole process is described in RFC 1796.

Using this naming scheme for FIG would require a second numbering scheme for PHP-Fig Standards. That would f.e. mean that there is a PHP-Fig Standard X that describes Coding Styles. The actual implementation is described by PSR-1 which then was "obsoleted" (Please, don't start a discussion on whether it was obsoleted or not, this is just to clarify the point!) by PSR-2 which might become obsoleted by PSR-12 as soon as that is finished and accepted. So for every PHP-FIG Standard there can be multiple successive PSRs.

Cheers

Andreas

[Rivera, John]

Nice explanation, that actually caused me to rethink my opinion on the matter. Thanks!

--
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+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/30c78335-5e7c-486f-8611-9e95ddcd0c5f%40googlegroups.com.

[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

[Hari K T]

Hey Larry Garfield, 

You have linked to the same form not the response.

I like your write up about the various problems that can occur if we go for psr/log 2.0 .

Hari K T

You can ring me : +91 9388 75 8821

http://harikt.com , https://github.com/harikt , http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT

Skype  : kthari85

Twitter : harikt

--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 php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/dd263211-d00d-82a7-98d9-1ca353503f89%40garfieldtech.com.

[Damiano Petrungaro]

I like the approach of namespacing the PSRs versions.

So the PSR number will be the same, and if there isn't new methods or interfaces (etc) introduced the PSR number will be the same one.

The only thing i don't like is the "V2" namespace. But the theory on namespacing is cool!

[Alessandro Lai]

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..

[Damiano Petrungaro]

Sure we can talk about it at @ PHPday.

I don't see the problem of versioning because the entire PHP ecosystem at the moment works with this """problem""" for multiple versions (and imho is not a problem).

You can PR the packages as Larry said, or use a forked version.

[Jordi Boggiano]

On 2017-05-08 03:01 AM, Larry Garfield wrote:
> 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.

Note that the packages could be updated to "psr/log": "^1.0 || ^2.0" if
2.0 is compatible with implementations supporting 1.0. Then it's up to
the users to pick psr/log 1.0 or 2.0 based on the PHP version they have,
or preference or whatever. Both can coexist if the changes are minor
enough (adding scalar type hints for things that were already enforced
counts as minor IMO). Doing a change like that doesn't require a major
version bump.

And no, not everything has to change overnight. It's much like when
Composer got started, nothing used it at first. If you wanted to use it
with a lib you had to send a PR with a composer.json to that lib..
Things moved pretty fast that way, but not overnight, there's no need to.

Best,
Jordi

[Larry Garfield]

The difference with Composer's initial adoption is that the presence of
a composer.json file does not break the library for non-Composer-using
projects. A dependency on a new version of a PSR definition package may
break it for anyone who hasn't updated.

--Larry Garfield

[Jordi Boggiano]

Only for new versions of the package.. You can still use old versions
just fine though. People migrate at their own pace.

It's the same with Symfony 3 (and soon 4) for example.. There are still
packages that haven't updated to support it. They require 2.x, and it's
annoying, but by and large this rarely happens because most projects are
updated quickly. Some symfony components are arguably more widely spread
than PSR packages, and things are working out alright there.

IMO this whole thread is a form of premature optimization.

[Cees-Jan Kiewiet]

And that is key in this to be honest. People will upgrade at their own and their projects' convenience. Having PSR-20 using the same FQCN as PSR-3 is the cleanest and more future proof option IMHO. Having 5 namespaces for the 'same' standard would create a mess and confusion. New major or minor versions is something we as developers are used to, namespacing each version not so much. Who knows what PHP 8 will bring, we might come up with PSR-80 that uses new and shiny features from it. I might end up writing wyrihaximus/cat that uses those features, which in turn will be incompatible with philsturgeon/turtle and micahaelc/tortoise unless they update. But in my humble opinion that is alright, and the way how software evolves over time. Projects are going to make choices based on what is compatible and what now and go with what is possible or create pull requests.

[Julien JANVIER]

For interoperability and upgrade purposes, it would greatly appreciated to not change the namespace of the package. All those concerns can be easily handled with a new branch on each package imho. The package are focused on a topic (psr/log), not on a PSR number.

And maybe it's stupid, but, why should name those branches 2.0?
Wouldn't it be easier and less confusing to have branches that stick to the PHP versions they are compatible with? Or maybe use aliases?

[Anthony Ferrara]

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