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
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.