Can we have a feature freeze before cutting a new release?

[1player]

I know I'm gonna get flamed to all hell here, but as much as I love hyprland (the only usable tiling WM that works with display scaling), every time there's a release something major breaks. (At the time of writing, Xwayland apps seem to be completely borked - #9214)

The ship-early-ship-often philosophy might work for a SaaS, but for a tool people might rely to do their work, I feel there is a lot of benefit from waiting a few weeks after major changes for bugs to pop up. There is a reason major open source projects go through half a dozen release candidates before shipping out. I appreciate the enthusiasm of the devs and how many breaking changes this project goes through, but there is something to be learned in matter of software release lifecycle. It is a bit tiring to fall in love with this project mid-release, see a new release come out with major problems, and have rollback or to go back to GNOME until the teething issues of the new version are sorted.

Hope this can be the start of a productive discussion and not some kind of silly flame war.

[nnyyxxxx]

Having a feature freeze wouldn't help bugs crawling into new releases, and new features being added doesn't always indicate a bug will be hidden in the commit as well. Most bugs can crawl out of all kinds of changes to the codebase.

I think pre releases would be better for weeding out bugs.

[1player]

Yes, feature freeze, pre release, whatever works best for your development model. The point is to let major or breaking changes sit for a while... I don't think users need the latest features out ASAP, and if they do, they can compile and run from the master branch themselves.

But taking 0.47.0 for example, as a "major version" (I know that technically it's still pre-1.0) it incorporates changes to the code base that were not even 24 hours old when the release was cut. A bit premature and risky, to my greybeard dev eyes.

Other projects, whenever they're ready to release, they create a new branch, tag a rc1 version and wait a few weeks before either getting a new rc out, or putting a bow on it and releasing it to the masses. The past year has seen HUGE changes to this project (such as migrating to aquamarine) that I feel benefit from a little more QA. Just my own 2 cents.

[Aqa-Ib]

We would need testers for both, the current git head and the release candidate. Without testers this would be useless, and even with testers there are a lot of usecases that will be missed. There aren't that many committed volunteers to achieve this task, we could try gathering more volunteers that would like to have this commitment with hyprland.

[vaxerski]

we have a tester group for releases, but obviously we can't catch everything. That's why if you need mission-critical stability, I always recommend to wait for .1 / .2

[1player]

Fair enough.. the issue is that distro maintainers don't know that so they'll update the hyprland package as soon as .0 is out.

…

On Fri, 31 Jan 2025, at 12:23, Vaxry wrote: we have a tester group for releases, but obviously we can't catch everything. That's why if you need mission-critical stability, I always recommend to wait for .1 / .2 — Reply to this email directly, view it on GitHub <#9236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIPSAOAOKEQA37STULQVD2NNTLBAVCNFSM6AAAAABWFXBFPSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBRG4ZTAMY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[UjinT34]

Switch to a more reliable distro? Most of them will have at least one testing stage before marking package as ready for everyone.

[UjinT34]

I guess LTS branch is more desirable than a feature freeze. That will require a lot of extra management and effort to make fixes both for main and LTS. Need someone willing to backport the patches.