Plasma 6 pre-release versioning
https://community.kde.org/Schedules/February_2024_MegaRelease#8_November_2023:_Alpha
gives us the following versions for Plasma 6's pre-releases:
Version | Name |
---|---|
5.80.0 |
Alpha |
5.90.0 |
Beta 1 |
5.91.0 |
Beta 2 |
5.92.0 |
RC1 |
5.93.0 |
RC2 |
Currently, the preview banner does not accommodate this: plasma-workspace#98 (closed)
I would like to suggest that we do not do anything special for the major version bump (major.minor.patch), but instead stick with the current versioning system (slightly modified for release candidates). This would mean we would have the following releases:
Version | Name |
---|---|
5.27.90 |
Plasma 6.0 Beta |
5.27.91 |
Plasma 6.0 Beta 2 |
5.27.92 |
Plasma 6.0 Beta 3 |
5.27.95 |
Plasma 6.0 RC 1 |
5.27.96 |
Plasma 6.0 RC 2 |
with master (5.27.80) being the development branch each of these patch pre-releases draw from.
For release candidates, we can split the .90 range in two, with .90 to .94 being betas and .95 to .99 being release candidates.
Alternatively, we could avoid calling them release candidates altogether, and just call them betas without changing the current system at all.
If release candidates imply a feature freeze, then we might want to use the release candidate range in our later minor releases, though they previously only recieve one public beta, which would then always be a release candidate unless we plan on having multiple (which we may well do, if we release biannually).
I suggest this for the following reasons:
- It's simpler.
- This would be the same versioning schema as our current one, just updated to allow for releases labelled as release candidates if we choose to stick with that instead of having more betas.
- This will enable us to determine the name of a release programmatically far easier (and extending the current preview banner code), rather than having to hardcode versions as Alpha, Beta 1, Beta 2, RC1, RC2. Worded differently, we would be able to determine the friendly name of a version according to a known schema that is valid for both minor and major upgrades.
- Current preview banner code accommodates both 5->6 and 6.0->6.1 properly, and would just need to be changed to recognise RC releases in the .95 to .99 range.
And I have the following issues with the proposed versioning system:
- I suggest we avoid 5.80.0 as this could cause confusion with patch .80, git master.
- I also don't see the need to have the first release arbitrarily called "Alpha" instead of being a beta.
- I believe this is to indicate a soft feature freeze. I think that making an initial beta release likely already implies this though.
- In the current planned versioning, 5.27.80 would be more properly named "Plasma 6.0 Alpha Dev", because the major release it is developing for is "Plasma 6.0 Alpha", 5.80.0. This is somewhat unwieldy, and applies throughout the planned 5.80+ range.
- This also suggests that the master branch would be changed from 5.27.80 to 5.80.80 to 5.90.80 to 5.91.80 etc, as each pre-release would be treated as a proper release, which I feel isn't necessary - we aren't going to use the patch .0 .1 .2 .3 etc as we are for any full releases because we aren't going to update them, as far as I know.
- Furthermore - these aren't proper releases, but would end up occupying a range with them as major releases currently do, only distinguished by using large values. We haven't done this before, so might be a point of confusion.
Sorry if this reads a little scatter-brained, I hope my point was communicated well.