New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Semantic Versioning (no BC in minor versions) #271

Neofox opened this Issue Sep 15, 2017 · 3 comments


None yet
4 participants
Copy link

Neofox commented Sep 15, 2017

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

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!


This comment has been minimized.

Copy link

froschdesign commented Sep 15, 2017

Some background: #270 (comment)


This comment has been minimized.

Copy link

weierophinney commented Sep 19, 2017

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment