Draft: [RFC] Xwayland-only release branches
There are new Xwayland features that we'd like to ship to users. Since there's currently no clear plan for a new major release of xserver as a whole, I'm volunteering to make releases of Xwayland only instead.
- New Xwayland development continues on the
masterbranch. Everything applicable must land there first, in order to prevent divergent forks of DIX code.
- When there are new Xwayland features ready to ship, a new stable
xwayland-<year>.<minor>branch can be forked off from the
masterbranch, and parts of the tree which aren't used by Xwayland can be pruned from that branch.
- Bug fixes can be backported from
xwayland-x.ythe same way as for the existing
- The initial major release and subsequent minor releases are made from the
- For release cadence, my suggestion would be to make a
<year>.1release in Q1 of each year, and if there are new features available by Q3, optionally make a
.2release as well. Releases should be aimed to align with regular Q1/Q3 distro releases.
xwayland-x.ybranch will be active at any time in general. There may be one final
x.y.zrelease from the previous branch after the next
Purpose of this MR
This MR isn't intended to be merged to the master branch. It's a proof of concept, demonstrating how
xwayland-x.y branches described above could start.
Contents of this MR
- The first commit is from !579 (merged).
- Drop autotools build system. While this isn't feasible yet for xserver as a whole, it is for Xwayland, so we don't need to deal with autotools on Xwayland-only branches.
- Drop DDXen other than Xwayland. The only exception is Xvfb, which is needed for some unit tests. However, this MR disables installation of Xvfb, even if it's enabled in the meson configuration.
miext/shadowsub-trees, which are only used by DDXen dropped from this branch.
- Build Xwayland unconditionally, change meson project name from
meson/ninja distgenerates an
xwayland-<version>tarball), and bump the version to 184.108.40.206 (for eventual 21.1.z releases).
Impact for other DDXen
There should be no direct impact, since Xwayland-only releases would be made from separate branches, and development continues on the
However, a similar approach might work for releases of other DDXen as well.
If there's a new full xserver major release in the future, Xwayland should probably be excluded from it similarly.
As always, it'll be up to each distribution to choose which release to ship Xwayland from, though obviously we'd recommend using the latest suitable stable release.
For Fedora 34, there's a proposal to package Xwayland separately from other DDXen: https://fedoraproject.org/wiki/Changes/XwaylandStandalone
This could happen regardless of whether there will be upstream Xwayland-only releases per this proposal. Without such releases, Fedora and other downstreams would have to similarly maintain their own branches forked off master instead. Upstream releases per this proposal would save effort for downstreams, and avoid fragmentation between distributions.
- February 3rd: Create
- February 17th: First release candidate
- March 3rd: Second release candidate
- March 17th: Final 21.1.0 release
I've created an
This milestone should be set on issues / MRs which need to be addressed or at least considered before the 21.1.0 release.