Use Semantic Versioning (no BC in minor versions)

[Neofox]

Hello guys,

Long story short, I work for a company which is migrating old code base to new PSR-compilant code and we use zend diactoros for that.
But we recently got problem with your versioning:

In recent updates of zend-diactoros:

zend-diactoros 1.5.0: remove support for PHP versions prior to 5.6 as well as HHVM.
zend-diactoros 1.6.0: #270 changes the behavior of the two SAPI emitters in two backwards-incompatible ways [...]

You pushed big breaking changes in your code and we got a lot of troubles in many applications because of your versioning.

if I quote semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

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

In general use-case, package versioning in composer is fixed by the version.
In this case if I fix in composer ^1.0 in my dependencies, I should only get non BC updates.

It can prevent code for breaking with a simple composer update

So please do something for the futur updates!

[froschdesign]

Some background: #270 (comment)

[michalbundyra]

About dropping old PHP version support:
http://www.doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html#why-dropping-php-support-in-a-minor-version-is-not-a-bc-break

And @Ocramius comment: zendframework/zend-code#129 (comment)

[weierophinney]

@Neofox — @froschdesign and @webimpress have provided a number of links explaining what we have done in recent releases, and why we felt these needed to be done without major release bumps. In particular:

• We do not consider upping the minimum required PHP version a breaking change. Quite simply, if our API stays the same, there is no BC break. Changing the constraints of a dependency, adding a dependency, or removing a dependency are not changes in our API. If your system is unable to consume the dependencies listed, Composer will appropriately choose the last stable version your system is capable of consuming. Your ability to upgrade to the latest version is not an indication of whether or not the version is still backwards compatible.

• With the most recent 1.6.0 release, we needed to make a number of BC breaks in order to fix a severe bug. In the vast majority of use cases, the changes we made will never be encountered; users will simply benefit from the bugfix without needing to make any changes to their own code. The changes were in classes that are typically neither extended nor directly consumed, which makes this a relatively safe change for our users.

Could you explain what exactly "broke" for you, and with what version(s) so we can get a little more background on your specific situation?