<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Backwards compatibility testing"
href="https://bugs.freedesktop.org/show_bug.cgi?id=86110">86110</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Backwards compatibility testing
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>wayland
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>ppaalanen@gmail.com
</td>
</tr>
<tr>
<th>Blocks</th>
<td>83980
</td>
</tr></table>
<p>
<div>
<pre>To ensure the continued backwards-compatibility of the Wayland protocol and
libwayland-server,client ABI, we should have some automated testing in place. I
very much doubt any developer ever tests mixed versions of different components
in purpose.
The components in play:
- Wayland (libwayland-server, libwayland-client, protocols)
- Weston
- an autonomous test app to be written, that excercises as much as possible
given the versions available
We would like to test building Weston and app against one version of wayland,
and run them against another version. This produces a test matrix on Wayland
build version vs. Wayland runtime version.
Only official release tags are the tested versions. Alpha and beta releases
should be included if resources allow. In addition, the master version of
Wayland and Weston should be included, so we can catch breakage before
releases. The rolling tests could run, say, weekly or more often if resources
allow.
Weston very often requires the contemporary version of wayland, which is fine,
and produces expected build failures. These should be found by testing rather
than pre-encoding the assumption. Once a test is confirmed to legitimately
fail, it can be marked as known-to-not-work.
We need some way to limit the combinatorial explosion, because both Weston and
the app maybe built or ran against different versions of wayland. It is also
useless to re-run tests with the exact same setup as before (unless the test
app is updated).
The essential idea is, that we would get an automated test bot, that ensures
that we do not break the backwards-compatibility of wayland.
There exists
<a href="http://upstream.rosalinux.ru/versions/wayland.html">http://upstream.rosalinux.ru/versions/wayland.html</a>
but I think doesn't cover the Wayland-specifics, like different code generation
between versions of wayland and how generated code gets built into compositor
and app binaries.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>