> For example, PipeWire in Debian Stable is at 0.3.65
Pipewire did/does not follow the strict semver versioning so you can't compare the two because the versions both start with "0":
- Pipewire had offered ~3 years of API and ABI compatibility on what it called "0.3.x", zig intentionally plans to break compatibility multiple times a year as it increments 0.x.
- Pipewire already planned to keep API/ABI compatibility between 0.x and 1.x, zig explicitly does not - they label the releases 0.x to signify these will break by 1.x
- Pipewire called 0.3.x stable for use but a rapid development version. zig is also under rapid development but they say they opposite in regards to stability guarantees.
I.e. the issue is more than "how do you get a newer version on stable Debian?" and more "it's an explicitly unstable package with no version compatibility guarantees, distros don't like packaging that in their stable repositories".
The easy answer to "be prepared" more or less is keep it in the dev repositories, like Alpine does, where there is no guarantee of stability or interoperability on updates. When zig declares itself stable (which, in its versioning scheme, will be 1.0) then it can just be added to stable without much work.
Pipewire did/does not follow the strict semver versioning so you can't compare the two because the versions both start with "0":
- Pipewire had offered ~3 years of API and ABI compatibility on what it called "0.3.x", zig intentionally plans to break compatibility multiple times a year as it increments 0.x.
- Pipewire already planned to keep API/ABI compatibility between 0.x and 1.x, zig explicitly does not - they label the releases 0.x to signify these will break by 1.x
- Pipewire called 0.3.x stable for use but a rapid development version. zig is also under rapid development but they say they opposite in regards to stability guarantees.
I.e. the issue is more than "how do you get a newer version on stable Debian?" and more "it's an explicitly unstable package with no version compatibility guarantees, distros don't like packaging that in their stable repositories".
The easy answer to "be prepared" more or less is keep it in the dev repositories, like Alpine does, where there is no guarantee of stability or interoperability on updates. When zig declares itself stable (which, in its versioning scheme, will be 1.0) then it can just be added to stable without much work.