Commit b8f38a3f authored by Emanuele Aina's avatar Emanuele Aina

long-term-reproducibility: Clarify scope

Try to clarify how products can rely on the release channels as a stable
platform and how version pinning/snapshotting is more meant as a
debugging tool.
Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
parent dbbd50de
......@@ -15,6 +15,20 @@ This document discusses some of the challenges related to long-term support and
how Apertis addresses them, with particular interest in reliably reproducing
builds over a long time span.
Apertis addresses that need by providing stable release channels as a platform
for products with a clear tradeoff between updateness and stability. Apertis
encourages products to track these channels closely to deploy updates on a
regular basis to ensure important fixes reach devices in a timely manner.
Stable release channels are supported for at least two years, and product teams
have three quarters of overlap to rebase to the next release before the old one
reaches end of life. Depending on the demand, Apertis may extend the support
period for specific release channels.
However, for debugging purposes it is useful to be able to reproduce old builds
as closely as possible. This document describes the approach chosen by Apertis
to address this use case.
For our purposes bit-by-bit reproducibility is not a goal, but the aim is to
be able to reproduce builds closely enough that one can reasonably expect that
no regressions are introduced. For instance some non essential variations
......@@ -176,15 +190,21 @@ The updates channel is not directly meant for production, but it offers to
product teams a preview of the pending changes to let them proactively detect
issues before they reach the stable channel and thus their products.
Stable releases are supported for 2 years, and product teams have three quarters
of overlap to rebase to the next release before the old one reaches end of life.
The stable channels thus are meant to provide a platform for products with a clear
tradeoff between updateness and stability. However, sometimes it is desirable to
reproduce the build as close to the original as possible, ignoring any update
regardless of their importance. To accomplish that goal the package archives is
snapshotted regularly, so that re-executing a recipe against a snapshot of the
archive installs exactly the same packages and versions as the original run.
While the stability of the release channels is suitable for most use-cases,
sometimes it is desirable to reproduce an old build as close to the
original as possible, ignoring any update regardless of their importance.
To accomplish that goal the package archives are snapshotted regularly,
storing their full history. The image build pipeline accepts an optional
parameters to use a specific snapshot rather than the latest contents.
This results in the execution installing exactly the same packages and
versions as the original run, regardless of any changes that landed in the
archive in the meantime.
To use a snapshot it is sufficient to change the APT mirror address, for
instance going from `https://repositories.apertis.org/apertis/` to
`https://repositories.apertis.org/apertis/20200305T132100Z` and similarly
for product-specific repositories.
## External artifacts
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment