Clearly, we should also have "should we drop PHP 5.4 support in SS4?" thread as well :-)

[Sam Minnée]

OK, so my question dropping PHP 5.3 support has raised heaps of people saying "let's drop 5.4 support as well!" despite my attempts to keep the discussion constrained. ;-)

The arguments for dropping 5.4 are basically the same as that of dropping support for 5.3: while we could get around the lack of language features, a bigger potential impact is whether modules we want to depend on will support that version of PHP.

As a specific example, SwiftMailer 6 is going to be PHP 5.5+, and it's quite likely that we'll want to replace our... antiquated... mailer implementation with SwiftMailer. Not being able to use the latest version of a core dependency is a bit sad-making, especially when SwiftMailer 6 has better unicode support (Dan Hensby knows more about the details of this)

But what does this mean for our users? Time for some actual data!

I've looked at a sample of SilverStripe 3.x installations from the last 6 months, and the PHP versions they are using. These are the stats that are send if you have "Send information about my webserver to silverstripe.org" checked on the web installer. Apologies for not having a nicer public interface for these, I've literally had to SSH onto the server and run MyQL queries directly to get the stats.

These were the stats:

Last 6 months:

SilverStripe 3 Installations by PHP version, 6 March - 6 August 2015

5.3 = 15%

5.4 = 26%

5.5 = 49%

5.6 = 10%

7.0 = 0.01% ;-)

And the 6 months before that, to see how changes are progressing:

SilverStripe 3 Installations by PHP version, 6 August 2014 - 6 March 2015

5.3 = 47%

5.4 = 26%

5.5 = 24%

5.6 = 4%

What's it indicates is that 5.3 is showing a pretty rapid drop-off, 5.5 is showing a rapid growth, and 5.4 is holding steady. We might assume that people using PHP 5.3 have felt compelled to move away from it in the year since the PHP team dropped support for it, and we can probably assume that something similar will happen with PHP 5.4. On top of that, PHP 5.4 use is already a lot less than PHP 5.3 use was 6 months ago.

SilverStripe 4 is, most likely, a little under a year away (we're thinking "mid 2016") and PHP 5.5 is already an extremely popular release. On top of this, major projects such as Symonfy are dropping PHP 5.4 support, and we can expect that a lot of packagist packages are going to follow suit. There will be a lot of pressure for people to move away from PHP 5.4, regardless of what we do.

I think it's probably a reasonable bet that, within a year, the figures for PHP 5.4 will be getting very low. Even if a few people can't install SilverStipe 4.0 the day it's released because they're not running PHP 5.5+, we should also recognise that by the time 4.0.1 or 4.1 comes out, the PHP 5.4 will have gotten even lower. And if people are really stuck in the mud, there's always SilverStripe 3.

However, even trying to project the figures a year ahead, I think that restricting SilverStripe 4 to 5.6+ would alienate a lot of users—probably more than half even in an optimistic scenario—and I don't think it's worth it.

In conclusion, I would support dropping PHP 5.4 support, but I would push back pretty strongly on dropping PHP 5.5 support. Dropping PHP 5.5 support feels like it would be putting abstract concerns ahead of the needs of too big a user group.

[Marcus Nyeholt]

PHP 5.5 and up is my preference, based on the underlying infrastructure we use for running SS sites :) 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Lamin Barrow]

I'm up for supporting PHP 5.5 and Up. Simply because regardless of which platform you develop on, you'll most likely end up deploying you code on a Ubuntu server.

The current Ubuntu 14.04 LTS version released last year will be supported until mid 2019 so you can imagine we will have PHP 5.5.x running on web servers for some time to come.

[Loz Calver]

+1 for 5.5+. I don’t think there are any language features that alone would justify this over 5.4+, but thirdparty libs will make this a necessity IMO.

SwiftMailer 6 as stated above and Guzzle 6 are both already 5.5+, Symfony 3 (and presumably [many|all?] of its components) will be too. Other libraries seem to be a mixture of 5.4+ and 5.5+ now, but I don’t think we can assume that will still be the case in a year or so’s time. We don’t really know yet which libraries we’ll want to take advantage of, but by sticking with 5.4 support we risk cutting ourselves off from the latest (supported) versions of them.

I wouldn’t be so willing to drop 5.5. Depending on when SilverStripe 4 comes out it may still be supported, and I think the LTS point is a good one: I’ve certainly encountered hosts who will only support the bundled PHP version as part of a managed service.

[Stevie Mayhew]

I think dropping 5.4 support is a great idea :)

I wouldn't go as far as dropping 5.5 support for 4.0, but this can be reassessed for 5.0 - I imagine that by the time 5.0 rolls around dropping 5.5 would also be a good idea.

I'd like to see any PHP release which has a <6 month lifetime left dropped on release, it makes sense to try and keep up with PHP security releases and language features.

[Christopher Pitt]

I think 5.5 is a good idea, given the recent efforts of component vendors (like Symfony) to support 5.5 and above. I'm all about us not re-inventing stuff that other people do well...

[Liam Whittle]

I’m for dropping 5.4 

A thing to keep in mind is that with shared hosting and the popular WHM/cPanel builds, cPanel only supports up to PHP 5.5 which is why you’re probably seeing the stats you are.

I’m sure in a year from now things will be different, but my thought process would be to support what cPanel does since it’s so popular.

On Thu, Aug 6, 2015 at 6:16 PM, Christopher Pitt <cgp...@gmail.com> wrote:

I think 5.5 is a good idea, given the recent efforts of component vendors (like Symfony) to support 5.5 and above. I'm all about us not re-inventing stuff that other people do well...

--

[Ralph Slooten]

Personally I'm not keen on dropping 5.4 to be honest, namely because we still use it on some of our servers (Debian 7.8 / "wheezy").

There was a (valid) reason given for dropping 5.3 - but what are the advantages of dropping 5.4, and what timeframe are we talking about?

Kind regards,

Ralph

[Sam Minnée]

Thanks, Ralph, that's a fair point. Upgrading servers is a good idea, but there are lots of good ideas in life and we don't always complete them all as quickly as we like. I'm definitely guilty of that. ;-)

We're expecting that 4.0 stable will be mid next year. So, a wee way off. After that point, we will still be producing security fixes for 3.x for some time, and 3.x will continue to work on PHP 5.3.

So, if you're still running Wheezy, the easy answer would be to continue to run SilverStripe 3.x. Ralph, do you see this as an appropriate solution?

What we haven't done yet is clarify when 3.x support will end. Perhaps we should nail that down at this time also?

Thanks,
Sam

[Conrad Dobbs]

Maybe it would be good to get some guidelines around release schedules and support for versions. Would tie in nicely with the new semantic versioning as I'd imagine major release versions are going to be more frequent now.

Maybe something like the tick tock schedule with LTS versions?

This is probably a separate discussion though...

[Ralph Slooten]

Debian Wheezy has LTS to May 2018 meaning it still has 18 months left of maintained security updates - and so I wasn't looking at upgrading in a particular hurry as upgrading tends to just "create more work". I'd rather not *have to* upgrade just because I want to use the latest stable SilverStripe ~ especially when I currently do not see any advantage (unless I overlooked it in the thread/s).

The point I was trying to make though, was, why increase the minimum requirements of SS in the first place? Personally I don't feel that arguments such as "<insert other CMS here> does it", or "trying to keep in line with some 3rd party software that could be possibly be integrated with SS" are valid reasons, unless for instance that 3rd party software is part of either the core framework or cms. I'm asking whether there are actual (valid) technical reasons why one would drop 5.4 support, and if so, why 5.4 and not, say, 5.5 etc. Will there actually be any significant improvements to SilverStripe by dropping 5.4 support, and if so, is it really worth it considering there are currently still 26% running on 5.4, or are you simply shooting yourselves in the foot and creating a lot more work than it is saving?

If there is a good reason then that settles it :-) I hope that maybe explains my perspective better?

[James Turner]

From what I understand, the 3rd party libraries being talked about will be part of the framework or CMS. I do understand where you are coming from regarding upgrading the OS, especially if you have to do it to many servers and given that the OS still has support for a while. The thing is, PHP 5.4 itself has an EOL of next month and doesn't extend to 2018. There isn't an insignificant number of people using 5.4 however I'm pretty confident that number is only going to get lower over time as both hosting companies and OS vendors increase the default PHP version. I don't think that in 10 months time there will still be 26% of installs running PHP 5.4

PHP 5.5 doesn't have any ground breaking new features but it does have some useful ones like support for "finally" blocks, generators or that the "empty" function can be passed arbitrary expressions. Could SilverStripe use these additional features? Probably. Will they want to? Maybe.

What type of support timeline for 5.4 were you thinking? Support until May 2018? If we treat the LTS version of Debian Wheezy as the PHP 5.4 support window, do we need to do the same for Ubuntu 12.04 LTS? It has support until April 2017 and its PHP version is only 5.3. How far do we go with this?

By May 2018, there may be 7 PHP versions that SilverStripe would need to support by then based on the fact that PHP has released a version since 5.4. I'm sure SilverStripe can probably spin up a few more test cases in Travis but is it really necessary?

As a platform, SilverStripe is great. As a codebase, there are some hairy parts that possibly could be optimised by utilising the features that PHP has in their supported versions. As much as it is a hassle if you have an older setup, I wouldn't want the framework to hold back on both functionality improvements and other optimisations for a long PHP support window on new major versions.

[Ralph Slooten]

I totally agree with you James, nor do I think that backwards compatibility should overrule progression of the SS framework & CMS - provided of course that (in this case) support for 5.4 is in fact "holding it back".

So the question is really: is the support for PHP 5.4 actually holding back development, or in any way having a negative impact on the SilverStripe framework & CMS? If anything, those statistics show this backwards compatibility as having a positive impact (allowing 26% of all the current recorded installations to run the latest software).

Yes there are theoretical scenarios where they might do this, or might do that, but that doesn't mean they are (or even plan to) in the near future.

I'm not asking anyone to maintain PHP support for as long as common Linux distributions continue to maintain their LTS distros - I'm just asking that this be taken into consideration before simply dropping support for PHP 5.4 simply for the sake of it and without a very good reason to do so.

[Christopher Pitt]

The Amazon S3 v3 SDK adapter, for Flysystem, requires 5.5. One of the main features planned for SS 4.0 is an overhaul of how assets are stored. We could use v2 of the S3 SDK; but judging from the difference in activity, and the EOL for PHP 5.4, there is no guarantee that v2 of the S3 SDK will be supported for much longer. Waiting to hear back, from Frank, about when he plans to bump the minimum version requirement for Flysystem.

The component SS uses to parse YAML is from Symfony. There was recent discussion and proposal of bumping support of Symfony components to 5.5. If we want to start using supported versions of that, and other Symfony components, then it's worth some consideration... :)

[Sam Minnée]

The other one that I know of is that the Swiftmailer 6, which will have better unicode support, is 5.5+.

None of these are insurmountable, but I think it's safe to say that there will be non-trivial barriers added by supporting php 5.4 that will lead us to either running older (possibly less well supported) versions of 3rd party libraries, embargoing interesting new features (like better unicode support) until SilverStripe 5, or writing more code ourselves. I doubt that we're going to rewrite code just for the sake of getting PHP 5.4 compatibility (we already have more than enough code to maintain), so realistically supporting PHP 5.4 will mean older 3rd party libraries and fewer features that libraries would have provided.

Regarding the comment of "don't drop support for the sake of it"—the counter point is that, if we are going to drop support, it would be nice to tell people sooner rather than later. This is the main reason I'm raising this now, despite the rationale for dropping PHP 5.4 support being a little vague.

Of the 9 people who have voice an opinion on this so far, we have 1 person suggesting that 5.4 support might be a good idea. 2 or 3 other people have informally advocated dropping php 5.4 support in other arenas. There is a clear majority, but even at a small sample size it's not unanimous, and the silverstripe-dev group is probably less conservative than the community as a whole.

Perhaps the best next step is to create a quick survey and get wider community input? If more than 25% or 30$% of people ask for PHP 5.4 support I would think twice about dropping support for it.

On Mon, 10 Aug 2015 at 15:01 Christopher Pitt <cgp...@gmail.com> wrote:

The Amazon S3 v3 SDK adapter, for Flysystem, requires 5.5. One of the main features planned for SS 4.0 is an overhaul of how assets are stored. We could use v2 of the S3 SDK; but judging from the difference in activity, and the EOL for PHP 5.4, there is no guarantee that v2 of the S3 SDK will be supported for much longer. Waiting to hear back, from Frank, about when he plans to bump the minimum version requirement for Flysystem.

The component SS uses to parse YAML is from Symfony. There was recent discussion and proposal of bumping support of Symfony components to 5.5. If we want to start using supported versions of that, and other Symfony components, then it's worth some consideration... :)

--

[keith / spronk]

I think the biggest factor here is 3.x support. PHP5.4 is already EOL basically, and 5.5 isn't that far off either. There's no real reason for a release mid next year to be considering 5.4 support IMO.

SS 3.x however is another story - as many have mentioned Debian 7 and Ub LTS will both remain 5.4 territory for another year or two, so it'd be nice to see SS3.x remain at least security updated until close to those dates.

My vote is 5.5+ for SS4.x

[Stevie Mayhew]

3.x lines will have to support 5.3 ongoing due to constraints within SemVer - thats fine.

I am for dropping 5.4 support - and rather than stating it like that, I think its nicer to say that I am for moving forward with 5.5. Make sure your survey doesn't induce bias due to the language Sam ;) :D

[off...@netwerkstatt.at]

Same here. I’ll have to update my server infrastructure, but I have to do it anyway. So switching to php5.5 or 5.6 is fine for me.

 

Old sites may remain on the old machine, that’s fine. And when customers want some new cool feature we need to upgrade to latest SS.

 

So for me it’s no problem to add another machine with php  5.5+ for new projects and leave the old server as is.

 

My vote is also for 5.5+ for SS4.x

[Daniel Hensby]

Zend framework 2 is also on 5.5 and they are releasing 3 this year.

It would be nice to be able to upgrade our legacy zend code too.

If we are identifying a lot of high quality and useful components that we want to move to for some of our core features, then we have to consider their version constraints and take them into account.

Whilst is like to be conservative and see a low version of PHP supported for longer, I don't support that in the face of progress, and if progress is using a high quality component then we do it.

Dan

--

[Anselm Christophersen]

I’m in for “latest & greatest”.

Let’s not waste precious time for having to reinvent the wheel.

Anselm

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Everyone

I am coming back to Ralph's question.  No one is stopping anyone from using PHP 7.0+ but what Ralph wanted to know is what the reasons are we need to go up to 5.4 or 5.5.   Is there anything that we want / need which requires us to set this as the minimum? If there is anything like  that (e.g. faster processing, better class management, cool new functions) then lets upgrade ASAP as we will have to do it anyway and by doing it now we will save a lot of time by making use of these cool new features. 

Nicolaas

Nicolaas Thiemen Francken
  www.sunnysideup.co.nz

  phone: +64221697577

[Sam Minnée]

This was covered in the previous comments - see the references to swiftmailer, zend, symonfy yaml parsing. If we need to support PHP 5.4, we can use any libraries that are PHP 5.5+

[Ralph Slooten]

As far as I'm concerned it looks like bumping the minimum version to 5.5 is the best solution. I was never against upgrading as such, but (as Nicolaas explained, probably better than I), the question was whether it was really necessary or not. By the sounds of it it definitely is, so it gets my vote then too.

:-)

[Patrick Nelson]

That being said, with the movement to SS 4 and the requirement for a minimum of PHP 5.5, the next question is (which may already be answered somewhere):

How long will SS 3.x security fixes be supported? Surely there will be a large amount of people using it after SS 4 is released and I bet there's probably a precedent already set (in terms of the amount of time it will be supported) by how long SS 2 was probably supported for security updates. The reasoning for this may be that, sure while SS 3.x supports old versions of PHP, there may be a lot of backward-incompatible features (plugins, custom features, etc) that were incorporated into the SS 3.x sites which will not transition smoothly or without great effort.

Extending this for as long as possible should hopefully provide a good reason for new people to actually adopt SS 4 with the knowledge that old versions are reasonably well supported without the fear of being alienated in case a new version happens to come out and left vulnerable.

[Steven Mohr]

+1 5.5+
We use ntPHPselector inside cPanel to allow selection of different PHP versions for various clients on the same shared hosting system.  Dropping 5.4 support wouldn't cause any issues for us.

[Will Rossiter]

Version support has been discussed within the core contributors and based on the discussion in this thread the decision has been made to drop 5.4 for SilverStripe 4.0. PHP 5.5+ will be required for running 4.0.

The 3.x line of development will continue to support 5.3 and 5.4 into the future and will be supported for 12 months after 4.0 is released to give everyone time to upgrade any required infrastructure.

Cheers

-- 
Will Rossiter
Sent with Airmail

On 6 August 2015 at 7:27:55 pm, Lamin Barrow (lamin...@gmail.com) wrote:

I'm up for supporting PHP 5.5 and Up. Simply because regardless of which platform you develop on, you'll most likely end up deploying you code on a Ubuntu server.

The current Ubuntu 14.04 LTS version released last year will be supported until mid 2019 so you can imagine we will have PHP 5.5.x running on web servers for some time to come.

On Thu, Aug 6, 2015 at 6:33 AM, Marcus Nyeholt <nye...@gmail.com> wrote:

PHP 5.5 and up is my preference, based on the underlying infrastructure we use for running SS sites :) 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Lamin Barrow
AKA deveSigner
P.O Box 4204, Bakau
The Gambia

Mob: (220) 9270190

Online at:

skype: barrowbros

http://devesigner.com
http://laminbarrow.com
http://twitter.com/laminbarrow

[Sam Minnée]

...and the PR is merged!

https://github.com/silverstripe/silverstripe-cms/pull/1303

 * Composer will no longer install silverstripe/framework:dev-master onto a PHP 5.4 system.

 * Travis is no longer testing PHP 5.4.

 * Changes involving PHP 5.5 features (e.g. generators, finally) will be accepted into dev-master (full list at http://php.net/manual/en/migration55.new-features.php)

 * silverstripe/framework and silverstripe/cms will be allow to require PHP 5.5+ dependencies (provided they're of high quality, useful, etc)

Thanks,

Sam

[Patrick Nelson]

Ah, refreshing :D

[Simon Erkelens]

Why not even drop 5.5?

Have the framework support up to 5.6 at the moment (Framework 3.2 ofcourse), switching it to LTS security releases, and have 4 only support 5.6 and up, would be drastic, agreed.
But what's stopping the drop of 5.5? "constantly" having to build failsafe options takes as much time, as just extending the support on 3.2, I think.

Even now, Debian7 customised repositories, allow sysadmins to upgrade PHP to 5.6. Same goes for Ubuntu Server and all other Debian related releases. I'm not a big CentOS user, but from what I know, it's easily done (in theory, agreed).

Besides that, even 5.6 is switching to security-only updates mid 2016. Considering Framework 4 would be released mid 2016, it would mean requiring support/security-updates, for a then-deprecated version of PHP.

When release-time comes, it would be good to have another look at the usecases, and based on that, make the decision maybe? Based on current statistics, I say go with 5.5 and up. Based on my brain's inner workings, I would say, just keep 5.6 and make sure an upgrade can be done safely without breaking too much.