First of all, consider that a package may be composed of different upstream tarballs, for various reasons. Real life examples may be docbook (docbook-xml and docbook-xsl repositories) and podman (podman itself, plus github.com/containers/image, github.com/containers/common and probably others).
At the moment there's only the concept of a package version, both in stone.yml and monitoring.yml. This version is exposed in the scripts via the %(version) macro.
Since SerpentOS has a focus on automation, it is currently impossible to automatically bump a package version. Suppose we want to bump podman to version v1.2.3: what version of github.com/containers/image should we use? What if the previous tarball is incompatible with the new podman release? A hypothetical boulder bump command wouldn't be able to bump all tarballs.
The current situation requires manual intervention. We may also need to use upstream versions in the script, which forces us to create (and manually update) variables instead of using macros akin to %(version).
First of all, consider that a package may be composed of different upstream tarballs, for various reasons. Real life examples may be
docbook(docbook-xml and docbook-xsl repositories) andpodman(podman itself, plus github.com/containers/image, github.com/containers/common and probably others).At the moment there's only the concept of a package version, both in
stone.ymlandmonitoring.yml. This version is exposed in the scripts via the%(version)macro.Since SerpentOS has a focus on automation, it is currently impossible to automatically bump a package version. Suppose we want to bump podman to version v1.2.3: what version of github.com/containers/image should we use? What if the previous tarball is incompatible with the new podman release? A hypothetical
boulder bumpcommand wouldn't be able to bump all tarballs. The current situation requires manual intervention. We may also need to use upstream versions in the script, which forces us to create (and manually update) variables instead of using macros akin to%(version).