change(docker): Publish fewer Zebra docker tags, and standardise names

[teor2345]

Motivation

We want the final set of DockerHub release tags to be:

• latest
• v1.x.y
• latest-experimental
• v1.x.y-experimental

To do this, we should:

Change:

• .experimental to -experimental to match the standard Docker/Rust format

Add:

• latest-experimental

Check docker pull statistics and decide if we want to stop publishing these tags for future releases:

• 1.x.y (use v1.x.y instead)
• 1.x
• 1
• sha-xxxxxxx (we might need to update some tests to use v1.x.y)

Docker Pull Statistics

To find out if we can stop publishing a tag, we can check which tags are actually being used:
docs.docker.com/trusted-content/insights-analytics/#view-the-analytics-data

Most engineers don't have access to that data, but @gustavovalverde does, or he can give someone an account.

Then if it tag isn't used much, we can just delete it. If it is used, we can announce its deprecation in one release, and delete it in the next. That way users have time to change their scripts.

Specifications

https://github.com/docker/metadata-action

Complex Code or Requirements

Currently Zebra is publishing a lot of tags:
https://hub.docker.com/r/zfnd/zebra/tags

If we stop publishing new uniquely named tags:

• some commands might fail if users try to fetch those versions

If we stop publishing updated existing tags:

• some users might silently stay on the previous version. This is worse because they expected updates with each new release.
• this mainly impacts the 1 tag

Testing

Check what tags get published on the internal Google Cloud artifacts. But they can be different due to workflow settings and the source branch.

Merge it, do a release, and check the tags.

Related Work

No response

[teor2345]

This change could cause release testing and publishing failures, so we should do #7680 first to make sure we get a ticket when the release fails.

[gustavovalverde]

To find out if it is a breaking change, we can check which tags are actually being used:
https://docs.docker.com/trusted-content/insights-analytics/#view-the-analytics-data

This is the month with the most downloads:

[gustavovalverde]

I'd handle user expectation from an holistic standpoint (not just our users). Based on that, I'd say that most projects are not worrying about having just a few tags, but those that are more representative for their use case. For example:

In other ecosystems:

• Postgres: 16.0, 16, latest, 16.0-bookworm, 16-bookworm, bookworm
• Nginx: 1.25.3, mainline, 1, 1.25, latest, 1.25.3-bookworm, mainline-bookworm, 1-bookworm, 1.25-bookworm, bookworm
• Python: 3.12.0-slim-bookworm, 3.12-slim-bookworm, 3-slim-bookworm, slim-bookworm, 3.12.0-slim, 3.12-slim, 3-slim, slim

Blockchain/our ecosystem:

• Rust: 1-buster, 1.73-buster, 1.73.0-buster, buster
• Ethereum: https://hub.docker.com/r/ethereum/client-go/tags
• Solana: https://hub.docker.com/r/solanalabs/rust/tags
• Chainlink: https://hub.docker.com/r/smartcontract/chainlink/tags

Based on this information (and the analytics), I'd lean to:

• Keep all the numerical tags: 1, 1.0, 1.0.0
  • This allows the user to decide if they don't want further updates 1.0.0, if they want to have hotfixes on each new pull (1.0), or if they want fixes and features (1).
• Remove the sha-xxxxxxx as all images have a digest reference

My only personal decision is keeping the v to have something that matches our GitHub's semver, but that's just personal preference and it can be removed, as this redundant with the numerical tags anyways.

Other decisions:

• Adding an alias or codename to our major versions, as for users it's somethings "friendlier", but not all projects use this approach. Something like zebra:foal, zebra:mare, zebra:stallion, zebra:grazer, zebra:quagga, etc.
• Adding the OS that we're using to build the image. This is not needed now, but if we're planning to do this in the future, it will be a breaking change in naming convention: zebra:1-bookworm, zebra:1-bullseye, zebra:1-alpine

[teor2345]

This is the month with the most downloads:

Can we also get the pulls for the latest month (October)?
For breaking changes, what people are doing now matters the most.

[teor2345]

@gustavovalverde ^

[teor2345]

• Keep all the numerical tags: 1, 1.0, 1.0.0
  • This allows the user to decide if they don't want further updates 1.0.0, if they want to have hotfixes on each new pull (1.0), or if they want fixes and features (1).

I think these are potential use cases, but I'm not sure if the Zebra project should actually support them.

For the health of the network, it is better that bug fixes and network upgrades are deployed as soon as possible. Our versions are all backwards compatible with cached state, RPCs, and configs, so that isn't much of a concern either. (And the breaking changes we do release have minor impacts for most users.)

Other builders or forks might want to support these upgrade policies, but we don't need to, unless there is significant user demand. Let's see what the response is from users?

We can do a post on the forums to get more feedback.

Other decisions:

• Adding an alias or codename to our major versions, as for users it's somethings "friendlier", but not all projects use this approach. Something like zebra:foal, zebra:mare, zebra:stallion, zebra:grazer, zebra:quagga, etc.

If we did this for Zebra, the current major version would be NU5, and the next one would be NU6. Or we could do what zcashd does, and use major version 6 for NU6.

Let's decide closer to NU6?

• Adding the OS that we're using to build the image. This is not needed now, but if we're planning to do this in the future, it will be a breaking change in naming convention: zebra:1-bookworm, zebra:1-bullseye, zebra:1-alpine

Let's decide when users ask for more than one base OS?

[gustavovalverde]

Can we also get the pulls for the latest month (October)?

@teor2345 September is the latest available:

[gustavovalverde]

If we did this for Zebra, the current major version would be NU5, and the next one would be NU6.

I like using NU5, NU6, etc...for consistency with the Zcash ecosystem.

[teor2345]

Ok, so for release 1.3.0 in October, only the latest tag is being used. That's good to know.