0

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
4

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.

| improve this answer | |
  • What do you think about adding a hint to semver’s metadata field? It’s excluded from any versioning related operations and has no specified semantic meaning. Imo info about the kind of beta would fit nicely there. – besc Jul 26 at 17:15
  • 4
    Why put it anywhere? It's not versioning information, it's metadata about your test planning. – Avner Shahar-Kashtan Jul 26 at 18:32
1

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.

| improve this answer | |
  • While it can be considered stable, and therefore public, wouldn't it make more sense considering this the pre-alpha stage? Since we can specifically define the prerelease stage. – Keimeno Jul 28 at 21:10
  • @Keimeno I don't understand your question. Any kind of beta comes after alpha. And anything that is released, whether it's alpha or beta, outside of your organization is not prerelease. – Thomas Owens Jul 28 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.