2.5.1 requires PHP >= 5.3, 2.5.2 requires PHP >= 5.5

[ecolinet]

We've just noticed that zendframework/zend-inputfilter has bumped the minimum required version in a minor release !

Is it possible de change that please ? that's a huge BC break !

I guess it is related to the use of ClassName::class in some part of the code.

[svycka]

It is not possible see: http://framework.zend.com/blog/zend-framework-2-5-0-released.html

[ecolinet]

That's sad, because according to semver.org :
"Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible
   manner, and
3. PATCH version when you make backwards-compatible bug fixes."

Does it means that zf2 is not following semver ?

2015-10-09 11:07 GMT+02:00 Vytautas Stankus notifications@github.com:

It is not possible see:
http://framework.zend.com/blog/zend-framework-2-5-0-released.html

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

[froschdesign]

@ecolinet
Please remember: PHP 5.3, 5.4 and 5.5 are obsolete versions! (http://php.net/supported-versions.php)

[manuakasam]

To be fair though, he has a point.
We argue that from now on modules are standlone in their version and don't
follow the "framework version identifier" anymore.

Changing the PHP requirements - even though if it simply had been forgotten
for 2.5.0 and 2.5.1 - is a mayor BC break and does require a new mayor
version.

This whole modular thing is still a new process for the Zend community but
I would argue that it is crucial that we keep the Semver intact. If we
can't rely on non-bc-breaks in minors that'd be quite annoying.

Frank Brückner notifications@github.com schrieb am Fr., 9. Okt. 2015 um
11:30 Uhr:

@ecolinet https://github.com/ecolinet
Please remember: PHP 5.3, 5.4 and 5.5 obsolete versions! (
http://php.net/supported-versions.php)

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

[ecolinet]

of course ... let's move the PHP versions of the 700+ PHP applications in
my company ...

but, in turn, please remember that following semver is the key of
interroperability between components in general. Regardless of how obsolete
a PHP version can be.

And by the way Ubuntu, Debian and Redhat maintains their own versions of
obsolete versions of PHP.

AFAIK Zend provides components for enterprises (that's one of the reason of
the choice of ZF2 to build enterprise application, over SF2, Laravel or
others) so they MUST follow semver IMHO.

For those of you, stuck with the same problem, here is the composer way to
use the LTS version of ZF2 :
"zendframework/zend-form": "^2.4.0, <2.5.0"

Maybe it can find it's way in the documentation ...

2015-10-09 11:30 GMT+02:00 Frank Brückner notifications@github.com:

@ecolinet https://github.com/ecolinet
Please remember: PHP 5.3, 5.4 and 5.5 obsolete versions! (
http://php.net/supported-versions.php)

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

[Maks3w]

"zendframework/zend-form": ~2.4.0 is enough for to keep on 2.4 series

[ecolinet]

Well for ZF2 components yes, but with a semver dep the caret is the safest operator (https://getcomposer.org/doc/articles/versions.md#caret).

[froschdesign]

@weierophinney
Can you make an official announcement as blog post?
And notice in all readme files would also be helpful.

[Maks3w]

Note InputFilter v2.5.5 == v2.4.8 both have the same code except the PHP 5.5 ::class sugar

[weierophinney]

We did document with the 2.5 release that we were upping the PHP version to
5.5. Simultaneously, we announced that the 2.4 series is now an LTS
version, specifically to support those still using older versions of PHP.
In the LTS information page (http://framework.zend.com/long-term-support),
we indicate you can pin to that series using the notation ~2.4.0 (which
is the recommended way to pin using semver in composer).

We recognize that we made a mistake in forgetting to update the minimum PHP
version when releasing 2.5. At the same time, we had already disabled CI
testing for versions <5.5, and claiming that the code still ran on those
versions would have been a lie. Hence, we did an immediate point release to
correct the error.

Finally: minor versions can certainly up the requirements of a project
without causing BC breaks in the actual public API. As such, they follow
semver. Whether you want to or can upgrade is another question entirely;
semver merely guarantees that if you do, you will not need to make changes
to your existing code targeting the public API of the project.
On Oct 9, 2015 4:43 AM, "Eric Colinet" notifications@github.com wrote:

of course ... let's move the PHP versions of the 700+ PHP applications in
my company ...

but, in turn, please remember that following semver is the key of
interroperability between components in general. Regardless of how obsolete
a PHP version can be.

And by the way Ubuntu, Debian and Redhat maintains their own versions of
obsolete versions of PHP.

AFAIK Zend provides components for enterprises (that's one of the reason of
the choice of ZF2 to build enterprise application, over SF2, Laravel or
others) so they MUST follow semver IMHO.

For those of you, stuck with the same problem, here is the composer way to
use the LTS version of ZF2 :
"zendframework/zend-form": "^2.4.0, <2.5.0"

Maybe it can find it's way on the documentation ...

2015-10-09 11:30 GMT+02:00 Frank Brückner notifications@github.com:

@ecolinet https://github.com/ecolinet
Please remember: PHP 5.3, 5.4 and 5.5 obsolete versions! (
http://php.net/supported-versions.php)

—
Reply to this email directly or view it on GitHub
<
#75 (comment)

.

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

[froschdesign]

@weierophinney
Thanks!

[ecolinet]

@weierophinney I perfectly understand
your point, and ~2.4.0 is perfectly valid to stick to the 2.4 LTS and so my
immediate problem is solved.

But I still think that changing the minimum runtime version is a MAJOR
change not a MINOR one and so ZF 2.5 should have been ZF 3.

[Ocramius]

Changing the dependency requirements (any) is not a BC break, as you simply
will be stopped from upgrading in case of unmet constraints. No broken code
reaches your prod environment.
This has already been discussed ad nauseam.
On Oct 9, 2015 15:53, "Eric Colinet" notifications@github.com wrote:

@weierophinney https://github.com/weierophinney I perfectly understand
you point, and ~2.4.0 is perfectly valid to stick to the 2.4 LTS and so my
immediate problem is solved.

But I still think that changing the minimum runtime version is a MAJOR
change not a MINOR one and so ZF 2.5 should have been ZF 3.

—
Reply to this email directly or view it on GitHub
#75 (comment)
.