A bug fixed on 2.9 but not on 2.8 (Curl Adapter)

[mvatansever]

Version: 2.8.3
Description: This bug not fixed on 2.8.* minor versions but fixed in 2.9.*

Code to reproduce the issue

Namespace: Zend\Http\Client\Adapter\Curl

        if ($connectTimeout !== null && (! is_int($connectTimeout) || ! is_numeric($connectTimeout))) {
            throw new AdapterException\InvalidArgumentException(sprintf(
                'integer or numeric string expected, got %s',
                gettype($connectTimeout)
            ));
        }

This bug causing on this commit and fixed on this commit or this commit. We use 2.8.* version of this package. Can you apply this fix on the 2.8 minor version?

Temporarily we are using 2.8.2 version but the final version(2.8.3) has the bug.

[Xerkus]

This project follows Semantic Versioning
You should upgrade to 2.9, it is backwards compatible to 2.8

[Xerkus]

@mvatansever any particular reason you decided to stay on 2.8.2 rather than upgrade to 2.9.x?

[weierophinney]

I've created a 2.8.4 release that includes the fixes from #168, which address the issue in the 2.9 series.

Since the 2.9 series requires an upgraded zend-stdlib (2.9 requires zend-stdlib v3, whereas 2.8 allowed v2 releases), this seems like a sensible solution.

[mvatansever]

@Xerkus yes, we have another dependency which depends on 2.8 version. I don't understand the semantic versioning how to avoid to release a new patch version?

@weierophinney thank you :)

[froschdesign]

@mvatansever

…we have another dependency which depends on 2.8 version.

Can you explain this in more detail? Thanks!

I don't understand the semantic versioning…

All informations can be found under https://semver.org

[mvatansever]

@froschdesign

Can you explain this in more detail? Thanks!

This package's 2.9 version depend on zend-stdlib v3 version but the 2.8 version depend on zend-stdlib's v2. The exact same issue described by @weierophinney .

All informations can be found under https://semver.org

Also, I don't see any problem and obstacle to release a new patch version by the approach of semver. I think it can be a patch version just for fixing this bug. Thanks again @weierophinney.

[froschdesign]

@mvatansever
Please don't get me wrong, I'm not against your request or the idea to support an older of version.
I wanted to clarify the "another dependency" and "I don't understand the semantic versioning".
No more, no less. 😃

[mvatansever]

@froschdesign the full sentence is more meaningful 😃

I don't understand the semantic versioning how to avoid to release a new patch version?

So we clarified each other with successfully 😄

[weierophinney]

Also, I don't see any problem and obstacle to release a new patch version by the approach of semver. I think it can be a patch version just for fixing this bug. Thanks again @weierophinney.

This was a special case.

The bug was introduced in a patch release, and we then immediately did a minor release. Typically, you can upgrade to minor releases without problems. However, in this particular case, we bumped the minimum required version of a dependency to a new major version, which is something that you often cannot update to using composer update without making changes to your application composer.json or first removing the composer.lock and vendor/ subdirectory.

In terms of obstacles to releasing a new patch, it can range from trivial to incredibly difficult, based on what changes happened to create the new minor release. If we have released the minor version in a way that developers can upgrade without problems, we will not backport patches.