Recent searches
Search options
Administered by:
@emersion Is there any opposition to release candidates for wlroots? Given that API breakages happen every minor release, doing a release candidate with even a one-week delay before tagging the final release would help a lot with ensuring that our wlroots-using compositors can quickly bump to the new version as soon as it's tagged.
@serebit Ah, in fact, I was wondering about this. So far we haven't been doing RCs because nobody asked for them. I did try to have a "slow pace" period before a wlroots release to fix up bugs (and decided not to merge a number of features too close to the release date).
How exactly do you think RCs would work? For Sway, we're doing RCs every week until no more bugs are blocking. For Wayland, we're doing a much more involved/slow thing with 2-week delays and alpha/beta stages that I'd hope to avoid. Do you have suggestions?
@emersion I say keep it simple. If you're already doing the "slow period to fix bugs" thing for wlroots, you may as well tag an RC at the start of that slow period, and maybe tag new RCs every N weeks until you're satisfied with its stability.
For example, you could finalize the feature set and API in 0.19, tag 0.19.0-rc1, and then tag new RCs every 2 weeks until there are no more blocking bugs—THEN tag 0.19.0 in place of a final RC.
(1/2)
@emersion By formalizing the slow period and making it obvious to downstreams, you would make it easier for us to jump onto a new version of wlroots before release. This benefits us by helping us line up a new release of our compositors with the new version of wlroots, and benefits you guys by giving us incentive to file bugs against release candidates. (2/2)
@serebit Sounds like other wlroots devs are on board with this plan, so we'll try it out for the next release. Thanks for the feedback!