What can be used as abbreviation for perpetual beta?

Question

According to Wikipedia, we talk about stages of development;

• prealpha
• alpha
• beta
• release candidate
• stable

But, beta also have 2 sub-stages;

• perpetual beta
• open/closed beta

Now if we were to version a software with these and semver. It would look somewhat like this:

• prealpha: 0.x.x
• alpha: x.0.0-alpha.x
• beta: x.0.0-beta.x
• release candidate: x.0.0-rc.x
• stable: x.x.x

However how would these look if we want to differentiate between perpetual and open/closed beta? Would this be allowed, and if yes would something like this work?

• perpetual beta: x.0.0-pb.x
• open/closed beta: x.0.0-ob.x, x.0.0-cb.x

Answer 1

These aren't really substages of beta, they're just different approaches to beta testing. I can't think of a scenario where you have both a perpetual beta and a temporary open/closed beta.

Similarly, the difference between a closed beta and an open beta isn't really meaningful in the versioning - the dev process might release v1.0.0-beta.1 which the product management might decide to keep as a closed beta, then v1.0.0-beta.2 which is released as open beta, then v1.0.0-beta.3 closed beta again, but after viewing results in the closed beta group, rereleased as open beta - but it's the same version, simply distributed to other people.

Don't use semver to encode data which isn't versioning data.

Answer 2

There are really two questions here:

• How can I use Semantic Versioning for an open beta?
• How can I use Semantic Versioning for a perpetual beta?

They each have their own answers.

To use SemVer for an open or closed beta, you would use it exactly as it's described in the question. The main segment of the version would reflect the target version that the beta is for and the metadata would be appended at the end. As an example, 2.0.0-beta+1 would reflect the first beta build for version 2.0.0. At the end of the beta, you could release this as 2.0.0 and be done.

It doesn't matter if the beta is open or closed. Open and closed just refers to who has access to the beta software. An open beta is generally available to anyone who wants to participate in it, while closed betas require the beta tester to somehow be selected for participation.

If you really wanted to, you could encode the metadata about open versus closed beta in the metadata portion of the SemVer string as well, but I'm not sure how necessary that is. I'm struggling to find a good use case for that, but it could be helpful to you or your organization to have that information.

Perpetual beta, on the other hand, is a different problem. The label of "perpetual beta" is used to indicate that the developer is frequently releasing new features or modifying existing functionality. The software typically has beta level quality, but it could be highly unstable with functionality being removed or changed. I don't think that this is necessarily compatible with SemVer.

If you wanted to use SemVer in perpetual beta software, I would recommend never incrementing the first version past 0. All of your releases would be 0.x.y. Consider this statement from SemVer:

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

That is the definition of "perpetual beta".

If you wanted to make a perpetual beta available, you can consider having development builds that meet beta quality available for consumption, either for download or in a special environment, while maintaining a stable and non-beta version elsewhere. This all depends on the type of software you are making and how you are distributing it.