Handling multiple server versions thanks to experimental
========================================================
Cyril Brulebois <[email protected]>


Context
-------

A quick overview of how things work upstream for the server:

 * Patches get reviewed and merged into the `master` branch.
 * After a few release candidates, `master` gets tagged (say: `1.10`
   or `1.10.0`), and a stable branch (`server-1.10-branch` in this
   case) is created to receive bug fixes.
 * Those bug fixes usually are cherry-picks from commits in the
   `master` branch.
 * This leads to stable bugfix releases: `1.10.1`, `1.10.2`, and
   so on.

It doesn’t make much sense to try and package `master` on a continuous
fashion, since the ABI can be broken multiple times, without a bump
for the ABI version numbers every time. It’s usually done once a bunch
of major changes landed, and when things are supposed to be stable
for a while. On the packaging side, as explained on the
link:dependencies.html[dependencies between server and drivers] page,
a bump means the need for a rebuild of the relevant drivers (input
and/or video).

That’s why the idea is to concentrate on upstream release candidates
and official releases. Depending on available developer time (both
upstream and in Debian), several branches can be developed/maintained
in parallel, so it can be worth having several versions available in
parallel, which is where `experimental` is handy.

Keeping on with this example, with `1.9` in `unstable`, release
candidates for `1.10` can be uploaded to `experimental`, along with a
few drivers so that it’s actually useful.


Selecting drivers
-----------------

To avoid repetitive and sometimes pointless work, it’s probably a good
idea to upload (to `experimental` as well) only a few drivers built
against the server in `experimental`. ABI might be bumped between
release candidates (that happened between `1.10rc3` and `1.10` for
example), so drivers would need to be rebuilt (even though binNMUs
might help).

The proposed drivers can be seen on the
link:squeeze-backports.html[backports policy for squeeze] page, along
with a tiny description for each.


Building drivers in experimental
--------------------------------

Having a driver in `experimental` doesn’t change much: It is sufficient
to declare a build-dependency against `xserver-xorg-dev (>=
$serverminver)`, where `$serverminver` can be seen in:

 * `debian/serverminver` in the `xorg-server` source package: see its
   first line.
 * `/usr/share/xserver-xorg/inputdrvdep`: see the needed version of
   `xserver-xorg-core`.
 * `/usr/share/xserver-xorg/videodrvdep`: ditto.

So, for a given version of a driver in `unstable`, bumping the
build-dep version and uploading to `experimental` should be enough,
providing it doesn’t require further changes (source code changes are
sometimes needed to support building against a newer server). When
that happens, the revision number can be constructed by appending
`+exp1`. The idea here is to avoid things like:

 * `1.42-1` to `unstable`.
 * `1.42-2` to `experimental`: bump the build-dep.
 * `1.42-3` to `unstable`: revert the build-dep bump, add a bugfix.
 * `1.42-4` to `experimental`: build the build-dep again, keep the bugfix.
 * etc.

Instead, that seems more natural:

 * `1.42-1` to `unstable`.
 * `1.42-1+exp1` to `experimental`: bump the build-dep.
 * `1.42-2` to `unstable`: add a bugfix to ++unstable++’s version.
 * `1.42-2+exp1` to `experimental`: rebuild against experimental
   (merging or rebasing the build-dep bump).

****
.Note

Remember `experimental` is special. With the above sequence of
uploads, if the `1.42-2+exp1` version isn’t uploaded, the
`1.42-1+exp1` upload might disappear from `experimental` after some
time, since the version in `unstable` is more recent: the “obsolete”
package goes away. That’s why it’s important to remember uploading to
`experimental` as well when uploading a new driver to `unstable`.
****