xserver release process

Adam Jackson ajax at nwnk.net
Tue Oct 8 16:28:55 UTC 2019


I gave a brief lightning talk about this at XDC Montreal [1], and
nobody seemed to object, but here's a recap for those who weren't
present or have other ideas or preferences.

In short, releases need to happen, and we have CI, so let's just pop a
release out on scheduled dates assuming CI passes. Six months seems to
be a pretty reasonable cadence for xserver major releases as new
feature development has tailed off a bit. Likewise for stable branches,
if there's been changes to the branch and it's been (say) two weeks
since the last release on that branch, and CI passes, automatically do
a new release. I intend to make this _entirely_ automatic, with a robot
doing the actual commits and release uploads.

Also, let's adopt the Mesa "last two digits of the year" version
scheme, it makes it easy to see how old your software is at a glance.
We'll need to be slightly careful about this to ensure we don't make
the (protocol) release number go crazy, so the scheme looks something
like this (underscores for clarity):

- xserver 1.20.5 → 1_20_05_000
- xserver 19.0.0 → 1_20_19_000
- xserver 19.0.1 → 1_20_19_001
- xserver 19.1.0 → 1_20_19_100
- xserver 20.0.0 → 1_20_20_000

Suggestions and comments are welcome, with the understanding that
anything much more complicated or too different than this implies that
you're volunteering to do all the work. (Not that that's a problem,
just letting you know what you're signing up for.)

[1] Starting approximately here: https://youtu.be/JIry8jpbPUY?t=32790

- ajax



More information about the xorg-devel mailing list