The road to v1.3.0 includes intermediate release with no bug fixes or new features, but infrastructure rework.

1.2.1 - Rework CI

• Rework and clean .gitlab-ci.yml
• Restore arm64 support (removed during 2024Q1)
• Instead of 4 build (current-protocol-support/ProtoALpha-protocol-support x octez-stable/octez-main) have 2:
  • stable: uses latest stable octez release (or release candidate) without ProtoALpha support
  • canary: uses master branch of octez and support ProtoALpha
  • proto_alpha branch is removed and ProtoALpha support is incorporated in main branch as a patch to apply when building canary
• Speed up CI using docker image with dependencies installed/updated instead of installing everything from scratch for each build

1.2.2/1.2.3/1.2.4/1.2.5_octez-v20.0 - Switch to GCP and change the versioning scheme

• AWS runners will eventually be shutdowned: switch to GCP. It has already been asked many times and will be mandatory soon^TM.

• GCP is very different from AWS. Fix the different builds. (Done. It has been a long an painful path)

  There's a big difference in the way the runner are built. We used to have a 1 job = 1 machine on aws Now we're running containers on a pool of machines... So, in the end, jobs are running concurrently, sharing resources.

  Indeed, additionnaly: arm64 offer on AWS is richer and more mature than that of GCP (AWS designs these CPUs itself with the Graviton family) whereas GCP has started > more recently and offers only a range of instances (t2a) Be in a VM and a container with sidecars as today generates stricter rules. CPU/RAM/Storage are not the bottleneck (we can provide more if it is proven that the problem comes from there) but the issues encountered so far are often related to the connectivity between the docker daemon and the client, I don’t know if your point is about a CI job with some docker build operations but if it is the case the solution would be to switch to buildx globally and generate multiarch from an amd64 container.

• Update the versoining scheme in order to include information about octez version used: MAJOR.MINOR.PATCH_OCTEZ

2.0.0 - Missing round information

• Record which baker failed to propose a block
• Use this new data in dataviz
• Deploy

2.1.0_octez-v20.1

• /missing.json and /available.json: spot level where rounds/blocks are missing

2.1.1_octez-v20.1

• 2.0.0 does not seem to work properly when deployed on NL's infrastructure. Fixed by updating database column types (bigserial + autoincrement instead of integer)

2.2.0_octez-v20.1

• /missing.json and /available.json: give level range as query parameter

2.2.1_octez-v20.1

• /missing.json and /available.json: fix data being sent multiple times (missing DISTINCT clause)