4 ms·

It doesn't have to be problematic. For example, PipeWire in Debian Stable is at 0.3.65 and probably won't get major updates until the next Debian release. How

It doesn't have to be problematic. For example, PipeWire in Debian Stable is at 0.3.65 and probably won't get major updates until the next Debian release. However, that's only part of the picture: Its early presence in Debian has paved the way for updates via the Backports suite, which is available to Stable users with a flick of a switch. With Backports enabled, Debian Stable has access to PipeWire 1.2.4, released upstream less than two weeks ago. This could be done for Zig as well. (Assuming Zig meets the Debian Free Software Guidelines. I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian.) https://backports.debian.org/ https://backports.debian.org/

rc00 2y ago
> This could be done for Zig as well. What's more, there is precedent with regards to Debian: Go is backported to Stable via the golang metapackage. The main package for Zig can follow the same structure and also be a metapackage with versioned dependencies. > I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian. As I understand, it would mean that Zig ends up in the non-free component rather than main or contrib.
zamadatix 2y ago
> 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.

rc00 2y ago

> This could be done for Zig as well. What's more, there is precedent with regards to Debian: Go is backported to Stable via the golang metapackage. The main package for Zig can follow the same structure and also be a metapackage with versioned dependencies. > I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian. As I understand, it would mean that Zig ends up in the non-free component rather than main or contrib.

zamadatix 2y ago

> 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.