Why doesn't the versioning system reflect common standards?

[Jaffa-Cakes]

I've noticed that breaking changes are made regularly using the minor field of the version number.

Normally, versioning is as follows: major.minor.patch - This system can be explained in better detail here: https://semver.org/

Breaking changes can be seen here that don't follow the versioning system above: https://github.com/webonyx/graphql-php/blob/master/UPGRADE.md

To my understanding since the current major version is 0, does this mean the library is still in alpha/beta? Why would that be so if the library includes every feature of GraphQL?

[simPod]

In the referenced document you can find this https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[Jaffa-Cakes]

@simPod

I understand that, but if this library already supports all GraphQL standards/features and has been developed since 2015 then why hasn't the library come out of initial development versioning?

[simPod]

@vladar is probably more competent to answer that.

As for me, it gives higher flexibility in changing things and that still happens very often. So it's easier to maintain in my POV.

[vladar]

@Jaffa-Cakes This library follows graphql-js versioning. They switched from 0.13.x to 14.0.x and we will for the upcoming 14.0 version (we lag behind them a bit).

See also: graphql/graphql-js#1005

[Jaffa-Cakes]

@simPod

Hopefully @vladar can shed some light on the topic.

I personally think moving out of initial development would be a good step to stabilise the library. Since all current features and things are added, it would make sense to move towards a more stable versioning system. This would make updating the library in applications it is used in less risky, alongside showing that the library has reached a reliable and functional state.