[Bug] Docker latest points to alpha

[mikesigs]

Our build scripts were using the :latest label in Docker to execute GitVersion with the following command

docker run --rm -v "$(pwd):/repo" gittools/gitversion:latest /repo

Something has changed recently where that command no longer outputs the JSON response, but instead it's printing out the visual tree of the repo. We're hard coding back to 5.11.1 now to fix things, but I figured I'd report this. I don't know what's of more concern, if the default behavior is changing to this tree output, or that the latest is pointing at a pre-release version. Shouldn't it point at the latest stable version?

[asbjornu]

Sorry for being harsh, but depending on :latest and expecting it to:

1. Always be stable
2. Never introduce breaking changes

…is by many experts considered an anti-pattern. In fact, providing :latest may for this very reason be something we should stop doing.

[tdspencer3]

A bunch of our pipelines also had issues. We understand the risks with using latest. But for us it has worked fine for several years. I don't think we expect either of the #1 or #2 arguments to be true. But we don't expect it to point to a pre-stable release version. We would happily fix our pipelines, test, and deploy to fix the breaking changes if it was a 6.0 stable release. But we aren't going to move our production processes to use something that hasn't been deemed production ready.

In addition, gitversion installed on my Mac through homebrew is still pulling 5.11.1. I don't specify to homebrew which version to install. I just expect it to pull the latest release. So dockerhub seems to be the exception to "latest" being an alpha release.

For the time being we have changed our pipelines to using the latest-5.0 tag. We would prefer the latest tags to be there, but to only point to stable releases.

[asbjornu]

The only thing we accomplish by having :latest point at the latest stable release is to postpone breakage. When v6 becomes stable and is released, it would still break every consumer of the :latest tag. Thanks for the input, though. We will consider this feedback going forward.

[arturcic]

@asbjornu I think we can tag again version 5.11.1 as latest and make sure we do not create :latest tag while we are in preview phase, or we can remove the :latest tag altogether making it clear you need to use a pinned version. What do you think is our way to go? To be honest I would go with removing the :latest making it explicitly

[asbjornu]

I agree. Let's just remove :latest. It's going to cause a bit of short-term pain, but it's much better for the long term.

[arturcic]

Ok then, I will remove the :latest tag from DockerHub, adapt the CI code, and update if needed the readme on DockerHub

[tdspencer3]

This is the kind of thing that I always fear as a developer, to report a problem and the solution is worse than never having said anything. I would not recommend going from one extreme to the other.

There are plenty of examples of heavily used images that move the latest tag to the most recent stable release. For ones I can find that have alpha-type images, the latest tag has not been pointed to it. That seems to be the common pattern that I have experienced.

Are you going to remove all the latest tags or just the one? I switched to using latest-5.0. Is that going to be removed as well? Will there be a latest-6.0 when its stable version is released? Will you come up with some other tagging scheme to follow the latest release such as lts or current?

As a user of this I would prefer to have the choice of what to use and the level of risk I am accepting by making that choice.

[asbjornu]

Since major versions indicate breaking changes, I think a moving target such as :latest makes no sense. No one wants to have their builds automatically broken due to :latest moving to a new major version.

That is quite different from :latest-6.0, though. Since that points to a specific major version, minor and patch versions can be released that won't cause any breakage. Therefore, using :latest-6.0 will preserve backward compatibility and be a safe choice "forever".

[tdspencer3]

I still think latest makes plenty of sense. I didn’t mind the breakage and accept the risks. The only issue I had was the latest pointing to a pre-release version. Our whole team was ready and willing to roll back to a pinned version, make the required changes for compatibility with the new version, test, and upgrade. That was, until we realized it was an alpha version. If latest was pointed to a 6.0.0 final release, I would have no issues with it at all.

[HHobeck]

Actually I agree with @tdspencer3 that it is a common behavior pointing latest to the version which has been released to manufacturing as a stable version. Everyone who is using latest knows that the usage is on own risk and he or she is aware of breaking changes.

@asbjornu: Just wondering why is it not possible to skip the alpha version tagging and only tag the final released one?

[arturcic]

@HHobeck it should be possible, we need to adapt the build scripts for that. Maybe it makes sens to keep the :latest tag for stable versions. The :latest-6.0 should be removed in this case and keep the :latest-5.0, and the :latest to point to :latest-5.0. @asbjornu do you agree with this?

[asbjornu]

Yes, I agree. :latest-6.0 makes sense only once v6 becomes stable. I don't mind keeping :latest to point at the latest stable release, but I also don't mind removing it. 🤷🏼

[arturcic]

In that case we can agree on setting :latest tag as latest stable. In that case the user of the :latest tag should be aware of the possibility of breaking changes in major versions. And as a recommendation is to use a specific version instead of the :latest. We need to update the readme on DockerHub with this recommendation.
I will have to re publish the :latest tag with the 5.x version and remove those with :latest-6.0, and adapt the build scripts accordingly.

[mikesigs]

Thanks all. I just got back from holidays to find this great thread. I like where you all have landed.

Just a few notes on how we're doing our own version for your consideration. We label each new stable version with four labels: :x.y.z, :x.y, :x, and :latest. This way :latest always tracks the latest stable major version, but you can pin to a major version (e.g. :5), or a major.minor version (e.g. :5.11), or of course the specific version (e.g. :5.11.1). Lots of flexibility!

What does latest-5.0 label imply in this repo? Any changes to 5.x, or 5.0.x?

[arturcic]

With the release of 5.12.0, the latest tag is again pointing to version 5.x.

[tewfik-ghariani]

Hii 👋 I hate to be the bearer of bad news, but this actually broke our pipelines

We are also using the latest tag and we are well aware of the risks involved.
Last month, the v6-alpha was released and our pipelines suddenly broke as a result.
We went through the breaking changes and adapted our pipelines accordingly. We have been using the v6 ever since

Now that the latest tag is pointing to v5 again, the changes made are no longer compatible and we would need to do double the work to revert and then re-apply our adjustments

Maybe it is hard to find a general solution for this problem, but at this moment, is it possible to also publish the v6-alpha docker image so that we can use the associated tag temporarily?

[arturcic]

The previous tags for 6-alpha1 are still there https://hub.docker.com/layers/gittools/gitversion/6.0.0-alpha.1/images/sha256-6291d5e167a97cee1b5f4c579d6b27138a055da25547170ec486007fa062daf1?context=repo