How to solve problems of parallel development of features in semver?

Question

Programming

Hello! Tell me, who solves the problem of versioning (semver) in parallel feature development?

For example, the case:
We now have version 1.8.0, a certain independent developer releases his feature into the alpha version, we make 1.9.0-alpha.1, then it stalls and solves a bunch of problems. At this point, another developer has prepared another feature. It is not correct to release it as 1.9.0-alpha.2, and in general it is not correct to give it 1.9.0, since this version was chosen for the feature of the first developer.

Well, ok, we release version 1.10.0 for the second developer, then the first developer wants to release it. Doing 1.11.0? Then we were left without the 1.9.0 version.

Share your experience or thoughts, please.

Answer 1

Didn't understand the problem. Whenever it is added to the master code, the product must remain functional. It is difficult to roll a feature at a time, so it closes with a toggle. The version does not increase when someone poured something, but when a release build is made for it and the number increases. Then this release goes into alpha. If the tests passed, then on prod. Well, of course, what with the fact that some version did not reach the release?
Do you have every developer making his own release? What does it mean to want to release?

Answer 2

Perhaps you do not really understand the essence of semver

We now have version 1.8.0, some independent developer releases his feature into the alpha version, we make 1.9.0-alpha.1, then it stalls and solves a bunch of problems.

The release is not tied to the release of a specific feature. It's just tied when you decide to publish a new set of changes and decide what will be released in that release.
Everyone merges their finished features into the master, after which you test it in its entirety and release it.
And delayed features will go to another release, so 1.9.0-alpha.1 should not be a specific feature release