Xserver driver merging pros & cons

[Peter Hutterer]

On Sat, Sep 17, 2011 at 01:23:27PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 17 September 2011 12:04, Matthieu Herrb <matthieu.herrb at laas.fr> wrote:
> > On Thu, Sep 15, 2011 at 10:45:17AM -0500, Jesse Barnes wrote:
> >> Cons:
> >>  [...]
> >
> >   3) makes it harder to maintain out of tree drivers, since API
> >      breaks are not going to be documented anymore.
> >      If old pre-kms code start to be removed, the people still
> >      depending on them will need a forked X xserver, which is not a
> >      good idea at all.
> 
> That's not actually true per se.  I don't think anyone has proposed
> doing this at all, and as someone who more or less thinks this is a
> reasonable idea, I'd be pretty upset if people stopped documenting API
> breaks.
> 
> Right now, we bump the ABI field in the loader as soon as the first
> ABI break of a development series is made for that particular
> subsystem, and then keep the ABI static from the first release
> candidate of a new major release, right the way through the stable
> series.  

I mentioned this in previous threads about this topic but
- I don't think that's a good approach since it hides ABI breaks, leading to
  interesting bugs that mostly waste developer time.
- the input ABI bumps more than once per version, if needed.

we have enough numbers left to afford multiple ABI bumps per server release
for the forseeable futures.

If we're really concerned about the numbers changing in an unpredictable
manner and the difficulty of associating the server with a specific ABI, we
should consider switching to a date-based ABI major. 20111119 or something
like that, provided the current range lets us do that (would need to check).
but tbh, I find the wiki page detailing the server vs abi versions enough.

Cheers,
  Peter