Currently releases are numbered as x.xxx – and the second part is just a unique number that is incremented on every build for uniqueness (Meaning of numbers after dot ?)
Building upon Debian Bullseye is around the corner! - #3 by ashthespy, the current version numbers makes it rather tedious to figure out if bugs are from os/core/ui/plugins or some interaction b/w them.
I would suggest using some form of loose semver, but instead of <major>.<minor>.<patch>+<meta> something that makes more sense for Volumio.
Something that captures OS/kernel/package changes in one field - this changes quite rarely, so <minor> might be appropriate. Another field should capture information from the core/UI/plugins. Ideally all these components use semver already to keep compatibility b/w their complex linkage. So as previously, we can use a field that ties all this in to just an incremental number for <patch>
So we have something like <major>.<rootfs>.<vol>. Since semver supports metadata, you can still add alpha/beta/test information, build, or any more creativeness.
| What | Version | Proposed |
|---|---|---|
Test v2.907
|
2.907 | 2.1.907+alpha |
| Build failure | 2.908 | 2.1.907+alpha+build2 |
| Test Tidal plugin | 2.909 | 2.1.907+alpha2 |
| Test Qobuz plugin | 2.910 | 2.1.907+alpha3 |
| Test core, abc,xyz plugins | 2.911 | 2.1.907+alpha4 |
| Test UI changes | 2.912 | 2.1.907+beta |
| Stable release | 2.913 | 2.1.907 |
New mpd/shairport-sync
|
2.914 | 2.2.907 |
| Change pi kernel | 2.915 | 2.??.907 |
| Change x86 kernel | 2.916 | 2.??.907 |
The new build system makes it easy to build a rootfs once that can be tagged and reused. Rather than building everything from scratch and chasing some bug that comes from an updated xyz package…
But this makes it confusing – if you change say pi kernel, keeping everything else constant, it would be 2.2.907 that isn’t very intuitive if you are used to semver.
Additionally versions of core – ui - plugins should somehow correlate to <vol>. This should be possibe by using semver across the ecosystem, and the minor version is then set as vol.
# dev cycle towards release 2.907
core : 2.<vol>.<patch> --> 2.907.4
ui : 2.<vol>.<patch> --> 2.907.2
plug_tidal : 2.<vol>.<patch> --> 2.907.15
plug_qobuz : 2.<vol>.<patch> --> 2.907.2
plug_xyz : 2.<vol>.<patch> --> 2.907.1
This lets you iterate the plugins/core/ui during the testing:
2.1.907+alpha → 2.1.907+beta → 2.1.907.
Pro tip - collect and store this version info somewhere on the image, makes it easy to back trace what change is causing issues. Given Volumio uses nodejs and modules, it’s a no brainier to use semver and tag module releases using proper package.json for each component/module/plugin. This allows you to use npm and such tools that focus on dependency integration.