arrow_back How to solve the problem of parallel development of features in semver?

Question

Hi all, how do you solve the problem of versioning (semver) when developing features in parallel?

For example, a case in point:
We currently have version 1.8.0, some independent developer releases his feature to the alpha version, we do 1.9.0-alpha.1, then he gets stuck and solves a bunch of problems. At that moment, another developer has prepared another feature. Release it as 1.9.0-alpha.2 is not right, and in general 1.9.0 give her not right, because this version was chosen for the first developer's chip.

Okay, so we do 1.10.0 for the second developer, then the first developer wants to do a release. Do we do 1.11.0? Then we are left without 1.9.0 version.

Share your experiences or thoughts, please.

Answer 1

Perhaps you don't understand the semver very well.

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

The release is not tied to the release of a specific feature. It's just tied in when you decide to publish a new set of changes and decide what goes in that release.
Everyone measures their own ready chips into the master, and then you test the whole thing and release it.

And the delayed features will go to another release, so 1.9.0-alpha.1 should not be a release of a specific feature

Answer 2

I don't understand the problem. Always when you pour into the master code, the product must remain functional. It is difficult to roll the feature at once, so it is closed by toggle. The version is increased not when someone poured something, but when a release build is made and it increases the number. Then this release is sent to the alpha. If the tests passed, then on the product. So what of course if some version didn't make it to the release?
Do you have every developer doing their own release? What do you mean wanting to do a release?

Comments

Leave it in the plan to stop making improvements? Then hide what is displayed in the interface, make it possible for the developer to enable himself to see these improvements. There can be any number of revisions in one version. A release will often contain code which people will see weeks or even months later, or may never see and will delete everything.

---

And the only way to pass the feature to the customer for testing is to publish an alpha or beta

---

At the moment we were developing a feature, we released a few alpha's and the customer asked us to leave the current feature and switch to another one. Unfortunately, we don't know yet what he will have in his head and which of the features we will release first.

---

Alexander Wolf , I edited the comment there, take a look. Why can't I increase the version in the wizard when the release version is done?

---

Not always the version increases in the wizard, unfortunately