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
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.
|Test Tidal plugin||2.909||
|Test Qobuz plugin||2.910||
|Test core, abc,xyz plugins||2.911||
|Test UI changes||2.912||
|Change pi kernel||2.915||
|Change x86 kernel||2.916||
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
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
# 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:
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.