> I'll rather use a really small, static (as in never changing) package [instead of one] that get updates every day and breaking changes from time to time. Tha

> I'll rather use a really small, static (as in never changing) package [instead of one] that get updates every day and breaking changes from time to time. That's an entirely fair point and, as I got into a bit in the versioning[0] section, something that I'm giving a good deal of thought too. I'm currently leaning towards tracking the Rakudo[1] compiler releases (~monthly), so updates wouldn't be anything like daily. As far *breaking* changes go – well, again, I'm still thinking about/discussing what guarantees to make, but I'm hoping to be able to promise to (try to) provide strong backwards compatibility. One thing I mentioned in the post is that Raku's strong support for multiple dispatch[2] makes backwards compatibility a bit easier: `_` can add a new version of a function without impacting the existing one. That still leaves _accidental_ breakage (i.e., bugs) – which is the area I'm currently most concerned about. If not handled correctly, a utility package risks creating its own sort of internal dependency hell: if there's a bug in one sub-package that you use, it could potentially block you from using that version – even if a different sub-package has a feature you want. I'm not sure of the best solution yet, but I'm exploring a few Raku options that I think may let me provide versions at the sub-package level (or maybe even the function level?). That's very much a WIP for now, but it's something that'll happen before a 1.0.0 release. [0]: https://raku-advent.blog/2021/12/11/unix_philosophy_without_leftpad_part2/#versioning https://raku-advent.blog/2021/12/11/unix_philosophy_without_... [1]: https://rakudo.org/ https://rakudo.org/