diff --git a/content/architecture/long-term-reproducibility.md b/content/architecture/long-term-reproducibility.md
index 58c041e231f03af315c0bb18d7deb53656bf5416..d787781246e47a2ccaa9a627c7a77f6f18af1d3f 100644
--- a/content/architecture/long-term-reproducibility.md
+++ b/content/architecture/long-term-reproducibility.md
@@ -261,9 +261,9 @@ version shipped in the Apertis repositories.
## Main artefacts and metadata
The purpose of the previously described software items is to generate a set of
-artefacts, such as those described in [the v2019 release artefacts
-document]( {{< ref "release-v2019-artifacts.md" >}} ). With the artefacts themselves a few metadata
-entries are generated to help tracking what has been used during the build.
+artefacts, such as those described on the [images]( {{< ref "images.md" >}} )
+page. With the artefacts themselves a few metadata entries are generated to
+help tracking what has been used during the build.
In particular, the `pkglist` files capture the full list of packages installed
on each artefacts along their version. The `filelist` files instead provide
diff --git a/content/designs/release-flow.md b/content/designs/release-flow.md
index 6348088820229adbfd89f5c3bfc6415a2636fd25..407f95eebca28402ef08e3c1fd1b57dccde9dfd2 100644
--- a/content/designs/release-flow.md
+++ b/content/designs/release-flow.md
@@ -456,8 +456,8 @@ documentation will be provided to explain what the scope of each example image
is, which use-cases it validates and which part of the software stack are
fully supported for product usage.
-For the 2019 product release this document can be found in the
-["Release artifacts for Apertis v2019"]( {{< ref "release-v2019-artifacts.md" >}} ) document.
+A description of the expected release artifacts can be found on the
+[images]({{< ref "images.md" >}}) page.
## Apertis release flow conclusions
diff --git a/content/designs/release-v2019-artifacts.md b/content/designs/release-v2019-artifacts.md
deleted file mode 100644
index f287a6d0796082ff6481fd24b74f22fb24fb611b..0000000000000000000000000000000000000000
--- a/content/designs/release-v2019-artifacts.md
+++ /dev/null
@@ -1,153 +0,0 @@
-+++
-title = "Release artifacts for Apertis v2019 [draft]"
-short-description = "Draft of the artifacts planned for the Apertis v2019 release"
-weight = 100
-aliases = [
- "/old-designs/latest/release-v2019-artifacts.html",
- "/old-designs/v2019/release-v2019-artifacts.html",
- "/old-designs/v2020/release-v2019-artifacts.html",
- "/old-designs/v2021dev3/release-v2019-artifacts.html",
-]
-outputs = [ "html", "pdf-in",]
-date = "2019-09-27"
-+++
-
-# Introduction
-
-This draft document describes which artifacts are expected to be part of the
-Apertis v2019 release and what are their goals.
-
-The main kinds of artifacts are:
-
-* ospack: rootfs without the basic hardware-specific components like bootloader, kernel and hardware-specific support libraries
-* system image: combines an ospack with hardware-specific components in a snapshot that can be directly deployed on the supported boards
- * Apt-based images: images meant for development, with a modifiable rootfs that can be customized with the [Apt](https://wiki.debian.org/Apt) package manager
- * OSTree-based images: images with a immutable rootfs and a reliable update mechanism based on [OSTree](https://ostree.readthedocs.io/), more similar to what products would use than the Apt-based images
-* OSTree repository: server backend used by the OSTree-based images for efficient distribution of updates
-* sysroot: rootfs to be used for cross-compilation for platform and application development targeting a specific image
-* devroot: rootfs for targeting foreign platforms using binary emulation for platform and application development
-* nfs: kernel, initrd, dtb and rootfs tarball for network booting using TFTP and NFS
-
-# Supported platforms
-
-Architectures:
-
- * `amd64`: the common Intel x86 64bit platform, also known as `x86-64`
- * `armhf`: the hard-float variant of the ARMv7 32bit platform
- * `arm64`: the ARMv8 64bit platform, also known as `aarch64`
-
-[Reference systems]( {{< ref "/reference_hardware/_index.md" >}} ):
- * `amd64`: [MinnowBoard Turbot Dual-Core (E3826)]( {{< ref "minnowboard_setup.md" >}} )
- * `amd64`: [VirtualBox]( {{< ref "virtualbox.md" >}} ) for the SDK virtual machines
- * `armhf`: [i.MX6 Sabrelite]( {{< ref "imx6q_sabrelite_setup.md" >}} )
- * `arm64`: [Renesas R-Car M3 Starter Kit Pro (M3SK/m3ulcb)]( {{< ref "rcar-gen3_setup.md" >}} )
-
-# Supported artifacts
-
-This is an overview of the release artifacts:
-
-* `minimal` ospacks
- * amd64, armhf, arm64
- * OSTree repository
- * Apt-based and OSTree-based system images for the reference hardware platforms
-* `target` ospacks
- * amd64, armhf, arm64
- * OSTree repository
- * Apt-based and OSTree-based system images for the reference hardware platforms
-* `basesdk` ospacks
- * amd64
- * Apt-based system image for VirtualBox
-* `sdk` ospacks
- * amd64
- * Apt-based system image for VirtualBox
-* `sysroot` ospack
- * amd64, armhf, arm64
- * tarball matching the target ospack
-* `devroot` ospack
- * amd64, armhf, arm64
- * tarball
-* `nfs` ospack
- * amd64, armhf, arm64
- * tarball and unpacked kernel artifacts for TFTP/NFS network booting
-
-## Minimal
-
-Minimal images provide compact example images for headless systems and
-are a good starting point for product-specific customizations.
-
-Other than basic platform support in order to succesfully boot on the reference
-hardware, the minimal example images ship the complete connectivity stack.
-
-The reference update system is based on OSTree, but APT-based images are also
-provided for development purposes.
-
-No artifact covered by the GPLv3 is part of the `minimal` ospacks and images.
-
-## Target
-
-Target images provide the most complete superset of the features offered by the minimal images,
-shipping full graphics support with a sample HMI running on top and
-applications with full multimedia capabilities.
-
-The reference update system is based on OSTree, but APT-based images are also
-provided for development purposes.
-
-No artifact covered by the GPLv3 is part of the `target` ospacks and images.
-
-The release also includes sysroots which include development tools, headers,
-and debug symbols for all the components shipped on target images. These
-sysroots contains software covered by the GPLv3 as they are meant for
-development purposes only.
-
-## Base SDK
-
-The base SDK images are meant to be run as VirtualBox VMs to provide a standardized,
-ready-to-use environment for developers targeting Apertis, both for platform
-and application development.
-
-Since the SDK images are meant for development, they also ship tools covered by
-the GPLv3 license.
-
-## SDK
-
-The full SDK images provide the same features as the base SDK images with
-additional tools for application development using the Canterbury application
-framework and the Mildenhall HMI.
-
-## Sysroot
-
-Sysroots are filesystem trees specifically meant for cross-compilation and
-remote debugging targeting a specific release image.
-
-They are meant to be read-only and target a specific release image, shipping
-all the development headers and debug symbols for the libraries in the
-release image.
-
-Sysroots can be used to cross-compile for Apertis from a third-party
-environment using an appropriate cross-toolchain. They are most suited for
-early development phases where developers focus on quick iterations and rely
-on fast incremental builds of their components.
-
-## Devroot
-
-Devroots are filesystem trees meant to offer a foreign architecture build
-environment via containers and binary emulation via the QEMU user mode.
-
-They ship a minimal set of packages and offer the ability to install all the
-packages in the Apertis archive.
-
-Due to the nature of foreign architecture emulation they impose a considerable
-overhead on build times compared to sysroot, but they avoid all the intricacies
-that cross-building involves and offer the ability to reliably build deb packages
-targeting foreign architectures.
-
-For more informations about using devroots see the
-["Programming guidelines" section](https://developer.apertis.org/latest/programming-guide-tooling.html#development-containers-using-devrootenter).
-
-## NFS
-
-The release includes artifacts for network booting using the TFTP and NFS protocols:
-* kernel images for the reference architectures to be loaded via TFTP
-* initrd with kernel modules matching the image to be loaded via TFTP
-* DTBs (compiled device trees) for the reference hardware platforms to be loaded via TFTP
-* rootfs tarball to be loaded via NFS
diff --git a/content/policies/images.md b/content/policies/images.md
index 193d7f33691e7c290c5d50a7ace5368d0d9a2ab2..81ec701759478c72955c65f74474ea8456fbb7fa 100644
--- a/content/policies/images.md
+++ b/content/policies/images.md
@@ -1,41 +1,140 @@
+++
-date = "2019-10-25"
+date = "2020-09-02"
weight = 100
title = "Images"
aliases = [
- "/old-wiki/Images"
+ "/old-wiki/Images",
+ "/old-designs/latest/release-v2019-artifacts.html",
+ "/old-designs/v2019/release-v2019-artifacts.html",
+ "/old-designs/v2020/release-v2019-artifacts.html",
+ "/old-designs/v2021dev3/release-v2019-artifacts.html",
]
+++
Apertis has a release lifecycle which is roughly three months long. Each
release consists of a round of development, testing and bug fixing,
-followed by a stable release. Apertis also has a daily set of images
+followed by a stable release. Apertis also has a daily set of artifacts
which can be used for the latest testing.
-You can find:
+You can find them here:
- - [stable release images](https://images.apertis.org/release/)
- - [daily build images](https://images.apertis.org/daily/)
+ - [stable release artifacts](https://images.apertis.org/release/)
+ - [daily build artifacts](https://images.apertis.org/daily/)
+ - [ostree repository](https://images.apertis.org/ostree/repo/)
Apertis is actively developed, so you should always develop against
either the latest release or the daily build images.
-There are five types of images available, depending on the platform:
+For the supported platforms, see
+[Reference Hardware]( {{< ref "/reference_hardware/_index.md" >}} ).
- - **minimal**: headless systems
- - **target**: systems with graphical stack and basic HMI
- - **basesdk**: full desktop environment to develop for Apertis, meant
- to be run under [VirtualBox]( {{< ref "/virtualbox.md" >}} )
- - **sdk**: full desktop environment to develop for Apertis with extra
- tools to write Canterbury and Mildenhall apps, meant to be run under
- [VirtualBox]( {{< ref "/virtualbox.md" >}} )
+The main kinds of artifacts are:
-The supported platform are (see [Reference
-Hardware]( {{< ref "/reference_hardware/_index.md" >}} )):
+* **ospack**: Rootfs without the basic hardware-specific components like bootloader, kernel and hardware-specific support libraries
+* **system image**: combines an ospack with hardware-specific components in a snapshot that can be directly deployed on the supported boards
+ * **Apt-based images**: images meant for development, with a modifiable rootfs that can be customized with the [Apt](https://wiki.debian.org/Apt) package manager
+ * **OSTree-based images**: images with a immutable rootfs and a reliable update mechanism based on [OSTree](https://ostree.readthedocs.io/), more similar to what products would use than the Apt-based images
+* **OSTree repository**: server backend used by the OSTree-based images for efficient distribution of updates
- - **amd64**: Intel 64bit (using UEFI)
- - **armhf**: ARM 32bit (using u-boot)
- - **arm64**: ARM 64bit (using u-boot)
+# Image Types
+There are a number of types of images provided by Apertis, depending on the
+platform, including:
+
+## Minimal
+
+Minimal images provide compact example images for headless systems and
+are a good starting point for product-specific customizations.
+
+Other than basic platform support in order to succesfully boot on the reference
+hardware, the minimal example images ship the complete connectivity stack.
+
+The reference update system is based on OSTree, but APT-based images are also
+provided for development purposes.
+
+No artifact covered by the GPLv3 is part of the `minimal` ospacks and images.
+
+## Target
+
+Target images provide the most complete superset of the features offered by the
+minimal images, shipping full graphics support with a sample HMI running on top
+and applications with full multimedia capabilities.
+
+The reference update system is based on OSTree, but APT-based images are also
+provided for development purposes.
+
+No artifact covered by the GPLv3 is part of the `target` ospacks and images.
+
+## Base SDK
+
+The base SDK images are APT-based and meant to be run as
+[VirtualBox]( {{< ref "/virtualbox.md" >}} ) VMs to provide a standardized,
+ready-to-use environment for developers targeting Apertis, both for platform
+and application development.
+
+Since the SDK images are meant for development, they also ship tools covered by
+the GPLv3 license.
+
+## SDK
+
+The full SDK images provide the same features as the base SDK images with
+additional tools for application development using the Canterbury application
+framework and the Mildenhall HMI.
+
+## Sysroot
+
+Sysroots are archived filesystem trees specifically meant for cross-compilation
+and remote debugging targeting a specific release image.
+
+They are meant to be read-only and target a specific release image, shipping
+all the development headers and debug symbols for the libraries in the
+release image.
+
+Sysroots can be used to cross-compile for Apertis from a third-party
+environment using an appropriate cross-toolchain. They are most suited for
+early development phases where developers focus on quick iterations and rely
+on fast incremental builds of their components.
+
+The sysroots contain software covered by the GPLv3 as they are meant for
+development purposes only.
+
+## Devroot
+
+Devroots are archived filesystem trees meant to offer a foreign architecture
+build environment via containers and binary emulation via the QEMU user mode.
+
+They ship a minimal set of packages and offer the ability to install all the
+packages in the Apertis archive.
+
+Due to the nature of foreign architecture emulation they impose a considerable
+overhead on build times compared to sysroot, but they avoid all the intricacies
+that cross-building involves and offer the ability to reliably build deb packages
+targeting foreign architectures.
+
+For more informations about using devroots see the
+["Programming guidelines" section](https://developer.apertis.org/latest/programming-guide-tooling.html#development-containers-using-devrootenter).
+
+## NFS
+
+The release includes artifacts for network booting using the TFTP and NFS protocols:
+* kernel images for the reference architectures to be loaded via TFTP
+* initrd with kernel modules matching the image to be loaded via TFTP
+* DTBs (compiled device trees) for the reference hardware platforms to be loaded via TFTP
+* rootfs tarball to be loaded via NFS
+
+# Supported Artifacts
+
+Here's a basic overview of the architectures and update mechanisms supported by
+each image type:
+
+| Type | amd64 | armhf | arm64 | APT | OSTree |
+| ---------- | ----- | ----- | ----- | --- | ------ |
+| Minimal | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Target | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Base SDK | ✅ | | | ✅ | |
+| SDK | ✅ | | | ✅ | |
+| Sysroot | ✅ | ✅ | ✅ | | |
+| Devroot | ✅ | ✅ | ✅ | ✅ | |
+| NFS | ✅ | ✅ | ✅ | ✅ | |