To clarify, once again, the versioning scheme: when a new development cycle starts, we bump up the MAJOR version, just like today we go from 3.EVEN_MINOR to 3.ODD_MINOR. Additionally, the alpha release would be the equivalent of the 3.ODD_MINOR.3 release we do these days. There wouldn’t be multiple alpha releases—considering people skip most of them anyway. In other words:
- 3.39.0 → [dropped]
- 3.39.1 → [dropped]
- 3.39.2 → [dropped]
- 3.39.3 → 40.alpha
- 3.39.90 → [dropped]
- 3.39.91 → 40.beta
- 3.39.92 → 40.rc
- 3.40.0 → 40
Plugin developers can keep matching on the MAJOR version, since we’re going to increment it every six months. If you introduce new API during the development phase, they are still going to ask for >= $MAJOR if they need an API. If you’re worried about API additions between alpha and beta phases, I’d recommend not to do them as a general rule, given that beta is when we freeze things, and alpha would be the month before.
In any case, I just checked how pkg-config deals with this issue.
A pkg-config file with a Version: 40.alpha is perfectly valid, and it does work as expected: the --atleast-version=40.alpha will match, whereas 40.beta will not. Additionally, if you change the version to 40.2 and use --atleast-version=40.alpha, the result will be successful.
This is with pkgconf, which has replace pkg-config in many places; I’m sure we can fix pkg-config to take into account alphabetic identifiers and sort them appropriately.
Meson’s version_compare() also works, by comparing chunks separately. We can probably fix things there as well, as I’m sure other projects will have to deal with this.