Codeception: Semantic Versioning for next release

[GaryJones]

_tl;dr Since there are breaking changes the next version should be 3.0.0, not 2.2.0._

---

I notice from the change log that there is nine _breaking_ changes listed for 2.2.0. None of these affect me personally, but _any_ breaking change could affect other developers. Two of these changes appear to be the removal of two modules.

Breaking changes are often needed for any software, and that's fine. The point here though, is that my project's tests shouldn't start failing because the test suite got updated to the same major branch which included breaking changes.

Semantic versioning is fairly well understood by a vast proportion of developers. Enough at least to understand the basics that for a version number of _x.y.z_, releases with just bug fixes bump _z_, releases with new features bump _y_, and most importantly, any breaking changes (changes or removal of API / interface) bump _x_. There's a little more to it than that, but that's the gist of it.

When someone does a composer update, or has an CI suite that checks out "^2" or "^2.1" of Codeception, then it will grab any version less than version 3. As things stand, after your next release, the automated suite will be checking out 2.2.0, and if they were using the Laravel4 module, or something else that has now changed, they aren't going to be happy and their build will fail.

If, however, you called the next release 3.0.0, as per semver, then they can decide if they want to update the Codeception dependency, and make changes to their code based when they want.

I'll re-iterate - my point isn't about what you've removed and changed (and it's great you've identified those changes in the change log), but about following a well-understood convention and using the version number to communicate intent to your users.

[dzoeteman]

Although I completely agree that this release should probably be 3.0 (even though PHP itself does small breaking changes in minors as well), I do want to note on one point:

has an CI suite that checks out "^2" or "^2.1" of Codeception

If your build that goes onto production does not grab the same version as you've developed on, you're probably not using composer.lock - it's recommended to include that into your repository to prevent these sorts of issues.

[DavertMik]

Yes, formally you are right. We have breaking changes and this should be called 3.0. However, I have my points why this is still 2.2. Despite the changes in core and some things that were broken, it is still Codeception 2.x. This means that upgrading to 2.2 should not be a lot of pain, as most breaking changes are related to:

• core changes which should affect only users who used some rare things, like mocks inside Cest classes.
• old modules which was not supported and are not recommended anymore. We had deprecation warnings for them.

Codeception 2.2 is pretty much the same Codeception. We still support PHP 5.4, we didn't introduce any breaking change in API, and so on. Technically it is a question of reasonability. I'd like to encourage users to upgrade and make this upgrade painless. The 2.2 number is psychologically better for this case.

[DavertMik]

Starting from 3.0 we will have semantic versioning. I promise :)

[Naktibalda]

@DavertMik Are you going to release 3.0.0 now?

[Naktibalda]

We are in much better place now.
All module repositories use semantic versioning.

We haven't introduced any breaking changes in minor or patch releases of Codeception 3.x and 4.x as far as I know, though I'm still guilty for not bumping Codeception to 4.2.0 when some minor feature was added few months ago.