Introduce 'stable' docker label

[oliv3r]

Currently, we have versioned tags (good) and latest, which tracks master (also good).

However users may be happy to run latest on development branches, local scripts, or occasional scheduled pipeline runs (to be aware of upcoming changes), but for general pipeline usage, they much prefer to run stable, which in theory should be slower evolving, and less-often changing.

The stable tag would just track the latest tagged release, so it would be a simple alias/link if anything.

This would give the opportunity, to say 'look, we want to stick to whatever @mvdan has released, but we do not want to be surprised by latest, we do have a occasional run to give us a preview of latest however and can plan and prepare for it'

[mvdan]

Personally, I didn't expect this would be wanted by users - if users want stability, they should probably pin a particular stable tag, and upgrade carefully as needed :) The upgrades are somewhat likely to change the format of files, for instance if bugs are fixed or the heuristics tweaked. Those should be handled in a controlled way, not automatically.

So I imagine users either want reproducible stability with pinning, or "don't mind stability" and use the latest development.

That said, I'll be happy to review a PR to add a new alias tag, because it can't hurt as a middle ground :)

By the way, in Go modules, latest does mean "latest stable", and it only falls back to "latest development" if there are no stable tags found. They do not have an alias for "latest development" yet (golang/go#42545), but I suspect they will at some point.

I bring this up because maybe it would be more intuitive to the average Go user to turn latest to be the latest stable, and move the current "latest development" to another alias such as tip or develop. Does Docker have any form of general standard for these?

[mvdan]

Also, in terms of "latest stable", I think we should use a tag name including the major version, such as v3-stable or v3-latest. Because the switch to v4 will certainly include breaking changes, and is thus not stable. Go also solves this problem by including the major version as part of the string before the version, e.g. mvdan.cc/sh/v3/cmd/shfmt@latest versus mvdan.cc/sh/v4/cmd/shfmt@latest doing the jump to v4.

[oliv3r]

Oh I agree in that having v3 (or v3-stable) makes a lot of sense as well.

My 'vision' is that I'd want to have 2 pipeline jobs. One that runs always (each commit etc) using latest stable, whatever version that may be. Then periodically, I'd track 'dev' monthly scheduled job, just to see where things are heading, what needs to be changed, so that when the 'stable bump' comes, I'd be ready. If I'm not, I could quickly change the tag from stable, to v3 and still be 'safe'.

As for 'latest' vs 'stable', hadolint actually produces a warning, that 'hey look, very often latest is basically dev, not stable, don't use it' :)

[mvdan]

I see, so :latest definitely doesn't have a "latest stable" meaning.

I think we should go for tags like stable-v3 or v3-stable, then. I don't have a strong preference for either. Perhaps stable-v3, so they all lexicographically sort together, away from the regular v3.X.Y tags.

I'd want to avoid v3, because that could be confused with v3.0.0, given how often v3.0 is a synonym for v3.0.0 as well.

[oliv3r]

I thing the post/prefixed variant of stable is definitely a decent idea; however the argument v3 being confused with v3.0.0 I'm not so sure of that one :)

Firstly, if we look at the most dockery container, the docker registry container, we actually see exactly that.
They have latest pointing at their latest stable (they don't do dev/master images it seems), which is fair, they initially coined the latest thing (just nobody cleanly follows it :p). Then they have v2.7.1, v2.7 and v2 all to help finding the latest stable within a series. (lets not look at docker in docker here, as they do follow the same, but it includes support for a lot of variants making it much harder to digest)

A few other, completely different images are for example sonarqube, busybox2 and python3 where they do a similar thing, albeit with a few flavors. Even ubuntu is doming something 'somehwat' similar, if you consider their 21.10 as 'one' version field.

Even alpine does this ;)

[mvdan]

If there's a strong understanding of what v3 means already, I'm not opposed to just that name. I do have a slight preference for being explicit, and I have seen some instances of people assuming v3.0 is short for v3.0.0, but I can't argue against a very widespread de facto standard.

(speaking of standards, I wonder whether the v prefix is aggressively non-standard)

[oliv3r]

The v-prefix, very good question; I see a little bit of everything. I do use it for tags for example. Semver says you shouldn't but does allow it :)

[mvdan]

Then I'd say let's just go for v3, with the assumption that such a docker tag format is already commonly understood to mean "the latest stable v3".

[oliv3r]

I agree! Shall I open a MR for this? Or are you happy to do this yourself @mvdan? (I'd have to figure out your push-setup first so its probably quicker for you :)

[mvdan]

I'll take a look as part of the upcoming release.

[mvdan]

I did the last release over the holidays and didn't get to this, but still intend to.

[mvdan]

Pushed the implementation straight to master after testing it via a dummy docker tag, as I want to release v3.4.3 today. Please feel free to review the changes after the fact, or send a follow-up PR if you can spot any improvement. I'll close this once the push of the v3.4.3 tag creates the docker tag.

[mvdan]

Done:

$ docker run mvdan/shfmt:latest --version
v3.5.0-0.dev-54-gb86b3247
$ docker run mvdan/shfmt:v3 --version
v3.4.3