Use proper SEMVER

PHP SDK
1

Hi,
First off thank you for the work you put into this library I do really appreciate it but,
I have recently updated multiple machines using the couchbase php-sdk just to find out that

  1. a new dependency was added that is not automatically installed with the upgrade.
  2. this dependency breaks a lot of userland code due to incompatibilities with sp_autoload* functions (https://github.com/flaupretre/pecl-pcs/issues/6).

Please for the future, use proper semver to prevent these kind of changes to go into a minor version,
and don’t label such breaking changes as:
<< This is the GA release of the 2.2.4 SDK. It is a maitenance release
with several fixes: >>
It’s not a maintenance release if it requires you to change the system that is using this library.

thank you

1 Like
2

semver is very important indeed.

3

This breakage wasn’t intended, and rather bug, and not API change. Our versions numbers are more about API, so we will fix the issue in next release, and increase major version when we will introduce backwards incompatible changes to interfaces.

4

Even when you fix a bug about API you need to follow semver.
Because someone may have used the API according to the current result of the version.

5

In this case, no API was changed. A dependency was added which semver explicitly allows for. Also, the addition was documented. In other words, we did follow semver.org’s spec.

That said, It’s been more problematic than we thought for folks. We didn’t see the same problems in our environment. So we’re planning to remove it under PCBC-443.

6

Yes you are right, sorry

7

I don’t know if you thought about it, but from the perspective here a more pragmatic approach than moving everything into C would also be ok, if not preferred: Moving the PHP part to the “user space”. The PHP part of the SDK could be a normal Composer package.

Pros:

  • No need for PCS
  • Not really much work.
  • The performance problems are gone. The PHP files are only compiled if needed. An opcode cache can further speed up things.
  • No need for separate stubs and stub updates in IDEs like PhpStorm any more. The IDE can fetch the information needed from the package and it is always up to date.
  • The users of the PHP SDK must often have look in the implementation of the SDK, because the API documentation is so rudimentary. They would have the information directly in the IDE.
  • At least theoretically the chance for code contributions from the user community increases, as the users are PHP developers and more likely will contribute PHP code.

Cons:

  • The installation process has two parts: Installing the C Wrapper and getting the PHP classes. It can be more work to sync the versions of the both parts.