On Thu, Dec 09, 2021 at 06:17:13PM +0100, Michel Dänzer wrote:
> On 2021-12-06 22:36, Matthieu Herrb wrote:
> > Hi,
> >
> > I don't understand why the 1.20.x -> 21.x.y change was needed, but I
> > can accept it.
> >
> > That said, why try to keep VENDOR_RELEASE in the form 1.21.x.y « for
> > backward compatibility » according to comments in meson.build and
> > confiugure.ac (in 21.1 branch) ?
> >
> > This causes XORG_VERSION_SNAP to be set to a non zero value in 21.1.1
> > and causes the following text to be displayed on startup, even though
> > this is a relased version.
> >
> > """
> > This is a pre-release version of the X server from The X.Org
> > Foundation.
> > It is not supported in any way.
> > Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> > Select the "xorg" product for bugs you find in this release.
> > Before reporting bugs in pre-release versions please check the
> > latest version in the X.Org Foundation git repository.
> > See http://wiki.x.org/wiki/GitPage for git access instructions.
> > """
> >
> > Some may make jokes out of the "It is not supported in any way."
> > sentence. Are relases any more supported ?
> >
> > I'd like to either submit a merge request to remove the PRE_RELEASE
> > test completely from xf86Init.c, or just drop the "compatibililty"
> > right shift of the version. I'm typeing this from an X server build
> > with
> >
> > VENDOR_RELEASE = (((21) * 1000) + ((1) * 10) + ((1) * 1000) + 0)
> >
> > and have found no issue yet. What was the need for this "backward
> > compatibility" ?
>
> Mainly for clients doing things like
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8999#note_799189 I
> think.
>
Someone tries to guess the future :)
So ihmo the solution is to get rid of the code considering the
versions with (vendorRelease % 1000) != 0 as development versions.
I'll prepare a MR.
Thanks.
--
Matthieu Herrb
