Are there any reasons for your request?

Yes: the concrete5 CMS uses version 2.7.7, but it doesn't work on PHP 7.3 because of the problem fixed in #91.
Since concrete5 still supports PHP 5.5 (we can't switch to a newer version because of its large user base), we can't upgrade to the 3.x series.

@mlocati
First:

• current version (3.2) is on active support
• version 3.1 has a long term support until 2022-03-15
• version 2.7 is outdated

Since concrete5 still supports PHP 5.5…

PHP 5.5 is dead since 21 Jul 2016 – 2 years, 2 months ago!

we can't switch to a newer version because of its large user base

I'm sorry, but if we would support you, then the next wrong signal for this user base would be given: stay on unsupported versions and do nothing.

we can't upgrade to the 3.x series.

Version 3 of zend-stdlib still supports 5.6, but with the end of the year version 5.6 and 7.0 are also dead.

@froschdesign Unfortunately since we are bound by our release cycle and semver we cannot drop support for PHP 5.5.9 in a minor version update and so we cannot upgrade away from zend-stdlib 2.7 until our next major version lands (Which is in active development and obviously a much higher supported minimum PHP version)

Sounds like the only way forward is for concrete5 to fork and deprecate so that we can maintain support of the PHP language for our actively supported version.

That simply means that your LTS release has an upper non-inclusive bound of PHP 7.3.0

Much simpler solution, much less pain in general.

zendframework/zend-stdlib support for 2.x already ended as per https://framework.zend.com/long-term-support

@KorvinSzanto

Unfortunately since we are bound by our release cycle and semver we cannot drop support for PHP 5.5.9 in a minor version update

1. The semantic versioning does not say you must or should support unsupported software versions on your own dependencies!
2. The semantic versioning is related to the public API of concrete5 and not to underlaying PHP version. (More infos on semver.org: "What should I do if I update my own dependencies without changing the public API?")

Sounds like the only way forward is for concrete5 to fork

This does not solve the problem that you supporting dead PHP versions. It makes the situation worse!

If we raise the minimum PHP required version in a dot release, I'm pretty sure I'll have to explain that a few thousands of times (literally).

@mlocati
Where is the problem for you or for concrete5? You already supported two PHP versions they are outdated for more than two years and without any security fix. With the end of the year you have 4 dead PHP versions!
Create a new minor release for PHP 7.1 and higher. If some of your users can not update or really do not want to do anything, that's fine. They can still use the current version of concrete5.

That simply means that your LTS release has an upper non-inclusive bound of PHP 7.3.0

That's fair, but just not the path we want to take unless we have no other choice.

I think it's completely reasonable that you do not want to make this change, we just want to make sure that our in-progress minor release supports as much as possible. With that in mind, we've already taken the steps to fork this repo so that's the path we're likely to take unless something changes here.

Create a new minor release for PHP 7.1 and higher. If some of your users can not update or really do not want to do anything, that's fine. They can still use the current version of concrete5.

This is something that we have not considered, but might be worth discussing further in our own circle.

I would absolutely argue that raising a minimum version requirement is a breaking change and so should not ever be included in a minor version release, but clearly there are people that disagree with me there.

I appreciate the consideration from you all on this issue, I think we've pretty well solved it at this point.