Versioning scheme for postmarketOS releases
Earlier I thought that it would be good to strictly follow Alpine's release numbers: our first release would for example be 3.11, based on Alpine 3.11. The upshot was, that we would not need a "complicated" mapping of postmarketOS releases to Alpine releases. However, this has the downside that we unnecessarily lock postmarketOS releases to the release cycle of Alpine (which is roughly every six months).
The mechanism of crafting a new release, testing it separately from the current release and giving users a certain time window for upgrading is something that we may not only want to use for Alpine releases. For example, we may want to only ship major UI upgrades with each new postmarketOS release, and possibly have that every two or even one months (or varying, depending on current upstream speed and other factors?). Which packages to "freeze" (only ship security updates) is a discussion that should be done separately: #21 (closed)
So in order to not tie the releases together unnecessarily and staying flexible in the long term, I suggest a new versioning scheme for postmarketOS releases. Keep basing on Alpine's latest channel, but make new releases when it makes sense for postmarketOS, not necessarily/just because Alpine made a release. Starting with a 1.0
number would be obvious, but:
- This indicates a stable product. Currently we are in alpha, I would call postmarketOS as a whole with the first release in beta state. We will gain a lot of new experience transitioning from the first release to the second (getting the upgrade mechanisms right etc), and I would wait for that until we label postmarketOS as stable (so have the second or third release the first stable one).
- Currently we are writing the pmbootstrap version to /etc/os-release, and pmbootstrap is already at
1.17.0
. This means, we have a clash in versions which I'd like to avoid.
Another scheme that comes to mind is YY.MM, like 20.04. Yes, that's also what Ubuntu is using, but I kind of like it because:
- the date of the release is directly obvious
- it's unlikely to clash with Alpine's versioning any time soon
- it does not clash previous pmbootstrap versions that we wrote to /etc/os-release
We could have a simple wiki page that translates the numbers. I've reworked the channels.cfg format (even before considering this new naming scheme) and now the postmarketOS version can nicely be listed as branch name - so this would not be an issue either.
Thoughts?