Draft: [RFC] Xwayland-only release branches
Premise
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.
My proposal
- New Xwayland development continues on the
master
branch. 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 themaster
branch, and parts of the tree which aren't used by Xwayland can be pruned from that branch. - Bug fixes can be backported from
master
toxwayland-x.y
the same way as for the existingserver-1.y-branch
stable branches. - The initial major release and subsequent minor releases are made from the
xwayland-x.y
branch. - For release cadence, my suggestion would be to make a
<year>.1
release in Q1 of each year, and if there are new features available by Q3, optionally make a.2
release as well. Releases should be aimed to align with regular Q1/Q3 distro releases. - One
xwayland-x.y
branch will be active at any time in general. There may be one finalx.y.z
release from the previous branch after the nextx.y.0
release though.
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.
- Drop
config
/exa
/miext/shadow
sub-trees, which are only used by DDXen dropped from this branch. - Build Xwayland unconditionally, change meson project name from
xserver
toxwayland
(someson/ninja dist
generates anxwayland-<version>
tarball), and bump the version to 21.0.99.1 (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 master
branch.
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.
Downstream impact
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.
Next steps
Xwayland 21.1.0 tentative release schedule:
- February 3rd: Create
xwayland-21.1
branch - February 17th: First release candidate
- March 3rd: Second release candidate
- March 17th: Final 21.1.0 release
I've created an xwayland-21.1.0
milestone.
This milestone should be set on issues / MRs which need to be addressed or at least considered before the 21.1.0 release.