xserver release process

[Michel Dänzer]

On 2019-10-08 6:28 p.m., Adam Jackson wrote:
> 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.

I like the idea of doing automatic release snapshots / candidates, but I 
think that's a bit too aggressive for actual releases at this point, at 
least on the stable branch. E.g. the recent 32-bit ABI breakage on the 
1.20 branch would likely have made it into a 1.20.y release with this 
scheme.


> 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

And then 1_21_*_* as of 21.x.y? Either way, sounds good.


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer