What are the consequences of using a non-semantic version number in composer for packagist?

Question

I want to publish a fork of a PHP library on Packagist. However as not really big changes may be made we want to use the official version number and just modify it a bit to add our own one.

So in the end we came up with the idea of a version number like this one: v1.1.3-CE.1. However there is a problem: This is not a semantical one. And especially for composer/packagist everywhere it is recommend to use semantical versioning. But as you can see it is still quite similar to a semantic version number, but we misuse the "pre-release version" "tag" (which is normally alpha, beta or similar). That's why I'd like to ask what effect non-semantically version numbers as our one have if we use them in composer? Are the updating processes affected e.g.?

If you really discourage us from using such a version number construction, we may also use a new version (starting from 0.1) for our fork, but we do not really want to do this.

Answer 1

If you fork, you have a new package. So you require a new package name.

Not renaming your fork will lead to problems. First of all, you will publish new versions of the same package name parallel to the original. This will lead to angry users if you succeed, but it is more likely that the original vendor name is protected on Packagist, so you already cannot publish the fork under the same name, no matter which version you assign.

So it is a new package name, but you are free to start with any version number you want. Note that semantic versioning does have different rules for the "0.x" series, specifically a minor update can break compatibility there. That's why Composer's ^ caret operator behaves differently: ^1.2.3 would allow updates up to 1.99999.99999, but ^0.7.1 will stay inside the 0.7.x range.

Don't overload the stability flag with something meaningless (i.e. I don't know what "CE.1" means or should indicate). Stability flags work great to tag pre-releases (with alpha indicating it is likely that incompatible changes will occur, beta indication compatible changes, and RC indicating only bugfixes) that are not meant for general public consumption.