[PATCH] render: reply with the server or client version, whichever is lower.

[Peter Hutterer]

On Thu, Sep 17, 2009 at 04:36:54PM +0200, Julien Cristau wrote:
> On Thu, 2009-09-17 at 21:52 +1000, Peter Hutterer wrote:
> > something like a single header file specifying the supported version for all
> > extensions rather than 25 SERVER_FOOBAR_MAJOR spread over different
> > source files seems sensible enough to me. Any comments?
> 
> Keeping the supported proto version in the same place as the code that
> handles the extension means there isn't one more file to forget to
> update when introducing new protocol, so I'm not sure separating them
> wins us anything here.  You don't usually extend more than one extension
> at once, so I don't see a reason to keep all the versions together.  I
> might be missing something though. :)

One benefit of a single file is that you can see in one go what protocol
versions are supported (see the recent configure.ac change). A side-effect
of this is that if someone changes the version for some other protocol they
are more likely to discover that another version is out of date.

Example: libXfixes/configure.ac states
dnl Version should match the current XFixes version. XFixesQueryVersion
dnl returns the version from xfixeswire.h, NOT the version we set here. But we
dnl try to keep these the same.  Note that the library has an extra
dnl digit in the version number to track changes which don't affect the
dnl protocol, so Xfixes version l.n.m corresponds to protocol version l.n,
dnl that 'revision' number appears in Xfixes.h and has to be manually
dnl synchronized.

configure.ac has a version of 4.0.3
the actual revision number define is 1 (back from 3.0.1). In between we had
4.0.0, 4.0.1 (woohoo, revision number define was correct agin), and 4.0.2.

libXcomposite has the same issue with revision defined as 2 since the golden
days of 0.2.2. We had 0.3.0, 0.3.1, 0.3.2 and 0.4.0 since.

The point of these examples is that maintaining version defines seems to be
difficult. Having them somewhere where others see them too even if they're
not working on that code might just help a bit.

But the real killer feature for me is the single-page list with all
server-supported protocol extension versions. Which would nearly count as
documentation.

Cheers,
  Peter