[Pre-Draft] PSR-Version

[Larry Garfield]

This was mostly written on an airplane somewhere over the North
Atlantic... :-)

PSR-Version is ready for pre-draft discussion, and includes an Editor,
Sponsor, and Coordinator.

PR is here:
https://github.com/php-fig/fig-standards/pull/628

Readable text is here:
https://github.com/Crell/fig-standards/blob/psr-version/proposed/version-support.md
https://github.com/Crell/fig-standards/blob/psr-version/proposed/version-support-meta.md

For the moment I've setup the PR to claim PSR-13, as the next number,
although it is my sincere hope that someone else proposes something and
takes that number before we do. :-( (Also, I think from now on all PRs
for Entrance votes MUST include updating the index page so that we don't
forget. Again.)

For the time being, *please ignore the specific timeframes in the
document*. Those are vastly subject to change, and I expect working
through those to be the main topic of discussion during Draft status.
Also, for my part the main driver of what those timeframes should be is
"whatever gets the most buy-in from projects and hosts". Shorter,
longer, don't much care as long as most everyone is on board.

The specific pre-draft input I am looking for is:

1) Does the concept overall appeal to you?

2) If you represent a project, would your project be willing to
participate (assuming timeframes that were amenable to you)?

3) Assuming this passes Entrance, would you be able/willing to assist me
in reaching out to projects and hosts to get them on board, or at least
get their input?

4) Assuming this passes Acceptance, would you be able/willing to assist
me in maintaining the list of participating projects/hosts? (That may
live in the meta doc, or may be a more public location, like
versions.php-fig.org or something. TBD, not relevant for now.)

Disclaimer: For the purposes of this PSR, I am acting as Editor, not as
Drupal representative. I haven't actually asked Drupal's release
managers about it yet as I don't want to distract them from Drupal 8. :-)

--Larry Garfield

[Dracony]

This seems like a great idea to promote hosts that perform frequent updates. But idk how much it is actually related to the whole framework interpolation. I mean it just might as well be a separate website which there are already tons of. Somebody would actually have to check these hosts every month or so to see if they have complied or not.

[Colin O'Dell]

Dracony brings up an interesting point.  The other PSRs don't have any type of date requirement - you're either compliant forever or you aren't.  PSR-Version for projects is also similar - a given release either is or isn't compliant, and this doesn't change with time.  But what about web hosts, which could be compliant today but fall out of compliance tomorrow?  Such a host may be advertising their compliance on their website, but can we trust them to keep this compliance info up-to-date?  Should these companies be policing themselves, or should there be some registry like http://phpversions.info/ which monitors compliance and keeps that information up-to-date?

Just some food for thought.

--
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/f99d1ffe-0d60-4c75-b058-7444d2d3193d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dracony]

Also, other PSRs are entirely self-declared. E.g. there is no site listing projects that comply to PSR-2.

Also hosting a site with what amounts to hosting recommendations is going to subject the person managing it to loads of spam. It is not hard to promise frequent PHP updates and literally every possible hosting company out there will try to get on the list, especially hosting resellers. You could argue that we would not allow reseller accounts, but again this requires policing them. If the only acceptance criteria is going to be proper versioning the application list will be absolutely polluted by cheapfreehostforguyzandgalz.com and the like. This type of thing is probably better suited for websites that already offer hosting reviews imho. 

Perhaps pushing a GOPHP7 campaign would be more feasible.

On Thursday, October 8, 2015 at 11:54:44 PM UTC+2, Larry Garfield wrote:

[Larry Garfield]

I disagree that the existing PSRs are "perpetual compliance".  Certainly a project could be using PSR-2-ish, and many do.  Drupal is using PSR-3 plus its own factory/routing object.  One could hack the crap out of composer and its PSR-4 support.

I see this as more akin to PSR-9: A process and workflow document.

phpversions.info doesn't actively monitor as far as I'm aware.  It's a glorified Wiki, albeit an attractively laid-out one.  That said, it's certainly a good resource and complementary to this effort.  The goal here is to also target projects, not just hosts.

--Larry Garfield

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

[Larry Garfield]

Not having a distinct "GoPHP7" campaign but an ongoing process is the whole point.  I don't want to have to go through all of this again every few years. :-)

I take it then your answer to question 4 is no? :-P

--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.
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/ea501576-16b1-4290-bca7-7ffe6fe4cda0%40googlegroups.com.

[Dracony]

Well I think hosting a list like you proposed woyld actually give great results in the long run, its just that idk who would volunteer managing it.

Releasing the PSR like any other though might actually work. It would leave it up to hosting companies to whether use it as a sales point or not. The fig could just release it and forget about it. In that form Id totally be backing it. At any rate it makes more sense than hug psr )))

I guess its time for me to silently buy the psrhosts.com and sell endorsements on it =)

[Korvin Szanto]

I know I looked over this and signed off on it, but I noticed a couple of expectations on the main document that I think we should change:

1. "A Minor Release of a participating project MUST support the most recent stable Major release of PHP older than twelve (12) months."

This might force a project to either release a major version or drop support for the PSR due to backwards incompatibility with a major php version. Maybe this should be a SHOULD?

2. "A participating host MUST NOT offer a PHP release that reached its End-of-Life more than twenty-four (24) months ago. Such versions usually have known security flaws and are a danger to users of those versions. This expectation applies only to newly created accounts."

While I agree with the sentiment I think that this is a "nice to have" requirement that will make it more difficult for hosts to comply, for example a host might see offering older versions as a competitive advantage. This PSR in my mind is only to make it so that we don't have hosts like Bluehost stuck on PHP 5.4 causing us to be forced to support it, not to prevent anyone from using old php versions.

And one final thought, would it be good to have a way to declare a release as not conforming in extraordinary cases so that we don't have to drop support for the PSR? All of the push back I've had on concrete5 supporting this PSR is the concern that we may NEED to make a release for a client or something and not have the ability to due to some other force of nature causing us to be behind PHP releases. I can't do much to combat that argument other than say "We can drop support for this PSR any time" or "I'll spend more time worrying about this!" which admittedly is a bit weak when arguing for supporting a standard.

Best wishes,

Korvin

--
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/e26ce5c6-699d-4f76-b9c6-2100cf26904b%40googlegroups.com.

[André R.]

Hi,

While intentions seems good, it is a bit unclear which part of "this" problem it tries to solve here in this group, and also which we actually *can* solve.

some smaller issues:

- it refers to versions and adds definitions of that, but could just as well refer to semVer for that part

- it refers to dropping support for older versions, but there are no rules around this for projects, just hosts

As for the dropping EOL PHP versions argument, this has a major issue:

- It overlooks one important part of the equation: linux distributions

Another thing overlooked here, current de-facto standard for minimum PHP versions are set by frameworks; until this year it has been 5.3, starting this year it is going to be 5.5, even if it is EOL from PHP. But many projects does not follow this, for instance Guzzle, which is somewhat a pain point for everyone else.

And while this proposal could theoretically help solve this part of the problem, it would in practice a pain point for users and hosts dealing with distributions. Only thing that has real potential to really solve that part of the problem is PHP LTS versions. It would also make this PSR much easier and easier to get support for, and would be a natural de-facto minimum supported PHP versions among libraries reducing dependency issues just a bit.

So in other words I think we need to push for PHP LTS versions as part of this effort in order for it to have real potential to make everyone's life easier.

On Thursday, October 8, 2015 at 11:54:44 PM UTC+2, Larry Garfield wrote:

[Larry Garfield]

On 10/10/2015 07:43 AM, André R. wrote:
> Hi,
>
>
> While intentions seems good, it is a bit unclear which part of "this"
> problem it tries to solve here in this group, and also which we
> actually *can* solve.
>
> some smaller issues:
> - it refers to versions and adds definitions of that, but could just
> as well refer to semVer for that part

True. I didn't reference SemVer specifically to avoid an external
dependency, but the wording there is open to revision.

> - it refers to dropping support for older versions, but there are no
> rules around this for projects, just hosts

Hm. I thought I'd included that. Yes, we should have such a provision,
probably similar to that for hosts. I think that's less important than
the inverse, though, which is insuring that new PHP releases are viable
ASAP.

> As for the dropping EOL PHP versions argument, this has a major issue:
> - It overlooks one important part of the equation: linux distributions

True. However, I see that as only a minor problem.

For hosts, to be blunt, any host that doesn't have the ability to
install and use supported PPAs for newer PHP versions (which are
available for every significant distribution) or compile their own (as
many do already) is not a host worth using.

For self-hosting organizations... the same generally applies. We don't
want to be hostage to a graybeard sysadmin at some corporation that
doesn't realize PHP moves faster than a snail. They're just as much a
target audience here; if they know what the PHP release and support
cycle is, they can better plan for it.

(I was a hostage to a client sysadmin that had PHP 4 running for an app
we built long after 5.3 was getting long in the tooth. It's definitely
an issue. But not being hostages is the goal.)

> Another thing overlooked here, current de-facto standard for minimum
> PHP versions are set by frameworks; until this year it has been 5.3,
> starting this year it is going to be 5.5, even if it is EOL from PHP.
> But many projects does not follow this, for instance Guzzle, which is
> somewhat a pain point for everyone else.

Yes, the "trend setter" frameworks would be a key target audience here.
If their version-deprecation cycles are more consistent and predictable,
it makes life easier for both hosts and users.

> And while this proposal could theoretically help solve this part of
> the problem, it would in practice a pain point for users and hosts
> dealing with distributions. Only thing that has real potential to
> really solve that part of the problem is PHP LTS versions. It would
> also make this PSR much easier and easier to get support for, and
> would be a natural de-facto minimum supported PHP versions among
> libraries reducing dependency issues just a bit.
>
> So in other words I think we need to push for PHP LTS versions as part
> of this effort in order for it to have real potential to make
> everyone's life easier.

I fear that getting Internals to adopt LTS releases is well out of scope
here, even if it would be beneficial.


--Larry Garfield

[Larry Garfield]

On 10/09/2015 05:41 PM, Korvin Szanto wrote:

I know I looked over this and signed off on it, but I noticed a couple of expectations on the main document that I think we should change:

1. "A Minor Release of a participating project MUST support the most recent stable Major release of PHP older than twelve (12) months."

This might force a project to either release a major version or drop support for the PSR due to backwards incompatibility with a major php version. Maybe this should be a SHOULD?

Hm.  Possibly.  I don't want to go as far as SHOULDing everything, as then the PSR has basically no teeth, but I'm open to discussing this point.

Note that even then, there are ways to do it.  Symfony, for instance, had classes named String and Integer and such. They fixed that by creating alias classes that PHP 7 users could use instead, and then the incompatibly named classes never get loaded.  PHP 5.x users can use the new names, too, to be forward-compatible.  So I'm not sure this is all that large of an issue.

2. "A participating host MUST NOT offer a PHP release that reached its End-of-Life more than twenty-four (24) months ago. Such versions usually have known security flaws and are a danger to users of those versions. This expectation applies only to newly created accounts."

While I agree with the sentiment I think that this is a "nice to have" requirement that will make it more difficult for hosts to comply, for example a host might see offering older versions as a competitive advantage. This PSR in my mind is only to make it so that we don't have hosts like Bluehost stuck on PHP 5.4 causing us to be forced to support it, not to prevent anyone from using old php versions.

I wasn't sure about how strong we could make that section.  To be fair, the "host must not offer" paragraphs have little impact on the overall goal (making sure new versions are available) and are more about killing off insecure software as quickly as possible.  Perhaps that section is unnecessary over-reach.

And one final thought, would it be good to have a way to declare a release as not conforming in extraordinary cases so that we don't have to drop support for the PSR? All of the push back I've had on concrete5 supporting this PSR is the concern that we may NEED to make a release for a client or something and not have the ability to due to some other force of nature causing us to be behind PHP releases. I can't do much to combat that argument other than say "We can drop support for this PSR any time" or "I'll spend more time worrying about this!" which admittedly is a bit weak when arguing for supporting a standard.

Hm.  I'm open to discussing it.  In practice, to be sure, a lot of this PSR will end up being "make a best effort" in practice, much like PSR-2 or PSR-9. 

--Larry Garfield

[André Jacques]

Hi Everyone,

This is my first interaction with you guys so I will introduce myself a little.

I'm a developer-analyst in the province of Quebec (Canada) playing with PHP for

about 7 years. I used framework such as Symfony and CodeIgniter and for now I'm

using mostly CakePHP. I have a "job" where I develop APIs and Web Application,

and I have a "company" where I want to change the world.

I've been interested in PHP-FIG for a while (at least 3 months) and now this

topic is what brings me to speak up. I found this PSR quite interesting because

I am very annoyed to see frameworks, hosts entreprises and even linux distros

not helping developer to go forward in the future.

So I saw in the comments that people have some problem with the use of MUST.

Some say it is needed otherwise the PSR become pointless. But there is others

who argues that first it will be difficult to follow and difficult to make sure

all those beautiful frameworks and hosts entreprise are "really" compliant.

I may have a suggestion that I post here, and I may, if require, PR on this.

We could add a new term, make it __Facilitate__, that would apply probably on

both framework but obviously more on host entreprises. This can be define by:

__Facilitate__: Make it easy for a end-user to access, configure and/or do

something.

We can then take things like:

"A participating host MUST NOT offer a PHP release that reached its End-of-Life

more than twenty-four (24) months ago. Such versions usually have known

security flaws and are a danger to users of those versions. This expectation

applies only to newly created accounts."

...and change it for:

"A participating host MUST NOT faciliate the use of a PHP release that reached

its End-of-Life more than twenty-four (24) months ago. Such versions usually

have known security flaws and are a danger to users of those versions. This

expectation applies only to newly created accounts."

What I see there is maybe:

* A user can't select a PHP version from the list while creating is account;

* A user may need to dig out in configuration settings;

* A user may have warning when such settings is configure.

But I guess that adding:

"A participating host MUST NOT offer a PHP release that reached its End-of-Life

more than thirty-six (36) months ago. Such versions usually break the 

Internet."

...would be appropriate.

[Michael Cullum]

So I just went through the Pull Requests and made a number of comments there, before thinking I should have really made them here and discovering most of my points had been made here already but I'll replicate (and expand on) them here anyhow.

There is a discussion going about "adding a clause to this document along the lines of "a project may not drop support for a supported PHP release in a minor or patch version". My thoughts on this are that this sounds like a good idea adding a clause about not dropping support for a x.y PHP version in an maintenance/patch release. However I can see it might be necessary to require a new version within a PHP branch (e.g. PHP x.y.z -> x.y.z+1) update in a patch/maintenance release in order to fix a critical bug. I also think this should be confined to dropping support within patch versions as sometimes major versions are not release for years (4 and a half years for symfony 2 -> 3, Drupal 7->8 will probably be about 5 years, phpBB 3.0 was 2007 [Although not semver so possible irrelevant]).

4) With regards to the keeping a list of participating projects/hosts, I do not believe the meta is the right place for this as the list will require regular updates and meta documents should only be changed when necessary (I'm not even sure if the bylaws actually require a vote to amend meta documents after approval of a PSR as most amendments so far have been Errata which do require votes) after approval.

On the wider point, I think having a list of participating projects and/or hosts is a good idea, but I don't believe this should be a centralised responsibility for the PHP FIG as I don't think we should commit to maintaining it indefinitely (you and others willing to maintain it might leave in the future) as it does require checking projects/hosts continue to abide by the PSR in order to maintain the reputation for quality that we have. I would rather that in the meta we suggest some third party sources (which could organised by FIG members, but it wouldn't be a FIG project) who provide such a list.

I also agree with André it might make more sense just to refer to SemVer for the definitions of major, minor and patch versions. We already reference other non-FIG standards in PSRs (Such as the IETF definition RFC for SHOULD, MUST etc.) so I don't think this should be a problem.

I would be for adding a new condition to the participating projects section which whilst it might deter away a few projects, I think it will make a much larger difference to web hosts, and that would be including a statement to say when participating projects should have *dropped* support for a PHP version is. I'd suggest this would be something for major versions only and something along the lines of not supporting a PHP branch that has been EOL'd for longer than 24 months. Otherwise all this is about is saying 'we will have support for versions by time x', without the thing that will really make the difference to (non-participating) hosts which is 'we will drop support by x'.

I think that in the participating projects section the line "A Minor Release of a participating project MUST:" should be changed to 'SHOULD' as the situation may arise where the only way to have support for a major PHP version would be to break BC. Furthermore, I think the statement " support the most recent stable Minor release of PHP older than ninety (90) days." should also apply to patch releases as well as minor releases. Minor releases in some projects only occur once a year which is quite a long time whereas maintenance releases are a lot more regular. Adding support for PHP minor releases should generally be considered a bug fix in my opinion and not new functionality. I can't really see any reason why it would take a minor release instead of a patch release to add support for a PHP minor version.

1) Speaking as myself, most certainly. 

1&2) From a phpBB point of view, it's something we're very interested in but obviously we'd discuss it internally at length further down the line whether to actually adopt it as it's only been discussed very briefly by the watercooler so far but consensus was it's certianly worth watching. Personally speaking, assuming the time frame and content in general is appropriate, I think it would be likely to be adopted. The problem would be we don't quite follow semantic versioning right now (we break BC in x.y) but we're looking to potentially 'fix' this in the near future. At the moment the PSR looks set to 'require' semver by participating projects.

3) Yes, I have quite a few contacts in those areas (Large hosts such BH and other EIG hosts) which could help. Feel free to drop me (or the list) a ping when we get there.

--

Michael Cullum

--

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/5e022905-dc4a-4714-89a4-ff40332daa62%40googlegroups.com.

[Michael Cullum]

Also, +1 to skipping PSR-13 and going straight onto PSR-14 in true PHP style.

--

Thanks,

Michael C

--

Michael Cullum

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.