Re: Latest and quarterly best practices

henrichhartzer@tuta.io writes:

> I propose that as a rule of thumb, if a package uses Semantic
> Versioning (semver) and the changes are non-breaking, it should be
> cherry picked into quarterly. Especially if this is only a patch level
> change and not a minor, but likely either way.

I tend to cherry-pick everything unless there's a good reason not to.
ABI breakage, POLA, insufficient QA, lack of user-visible changes,
churn fatigue, different maintainer or lack of time are such reasons.

For example, backporting vulkan-* is mostly churn compared to
backporting mesa-devel which brings actual Vulkan improvements.

> An opposite case, and this one may be truly a no harm no foul case:
> x11-wm/hyprland was updated from 0.33.1_2 to 0.34.0, and cherrypicked
> to quarterly. There were a number of changes in this release, and I
> personally would be hesitant to recommend such a cherrypicking unless
> there were known issues with 0.33.1 that users had complained
> about. Otherwise, since it's an offline window manager, it seems like
> waiting for the quarterly release would make the most sense. Now in
> this case I don't know the context and cherrypicking may have made
> complete sense -- I'm just using it as an example to try and explain
> my thoughts.

Wayland ecosystem moves fast. Hyprland is even faster, outpacing Sway.
0.34.0 made it easier to use plugins, removing the need to create ports.
0.33.0 removed NVIDIA hacks to bundled wlroots, helping FreeBSD port.

- Before 1.0 versions have no stability guarantee
- Upstream[1] and the Discord community don't support old releases
- Old releases are frequently buggy
- Backporting generic bug fixes is risky
- I don't want to support old versions of this

[1] At least the documentation is versioned, see
    https://wiki.hyprland.org/version-selector/