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.