Update Docker Image Tags

dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET

https://learn.microsoft.com/dotnet/aspire

MIT License

2.99k stars 283 forks source link

Update Docker Image Tags #3948

Closed eerhardt closed 2 weeks ago

eerhardt commented 2 weeks ago

Following this policy:

never 'latest' unless absolutely no other option (and then we should evaluate why that is with the owner)
major.minor
if no semver, choose most recent version

Containers that don't follow this pattern:

CosmosDB Emulator uses 'latest'
Azure Storage Azurite doesn't have major.minor
Kafka doesn't have major.minor
Oracle doesn't have major.minor
Qdrant doesn't have major.minor
Redis commander uses 'latest' (hasn't been updated in 3 years)
SqlServer has <year>-latest, which is roughly equivalent to major.minor

Fix #3933

Microsoft Reviewers: Open in CodeFlow

Zombach commented 2 weeks ago

Shouldn't it be taken into account in this case for tests that the current version in most cases will be returned as major.minor.revision. Provided we can set major.minor or just major?

eerhardt commented 2 weeks ago

Shouldn't it be taken into account in this case for tests that the current version in most cases will be returned as major.minor.revision. Provided we can set major.minor or just major?

I'm not sure I follow your question. What does "in this case for tests" mean?

danmoseley commented 2 weeks ago

Did you review these heuristics with our docker folks like @richlander ?

Zombach commented 2 weeks ago

I'm not sure I follow your question. What does "in this case for tests" mean?

I would like to understand what I wanted to ask you :D

Well look. For example, let's take Redis and specify the version "7.2 major.minor", then when running the test, in theory, the version should be specified as "major.minor.revision:7.2.4"

That's what I originally thought. But I confused myself. After all, in reality the version will be "7.2 major.minor"

All in all, never mind.

eerhardt commented 2 weeks ago

Did you review these heuristics with our docker folks like @richlander ?

I've chatted with @richlander @mthalman and @MichaelSimons about this all separately.

richlander commented 2 weeks ago

I like the direction.

radical commented 2 weeks ago

Should the policy being followed here be documented somewhere for future reference?

eerhardt commented 2 weeks ago

Should the policy being followed here be documented somewhere for future reference?

You mean in a .md file in the repo? Would there be an advantage to that over just referencing this PR and corresponding issue #3933?

eerhardt commented 2 weeks ago

/backport to release/8.0

github-actions[bot] commented 2 weeks ago

Started backporting to release/8.0: https://github.com/dotnet/aspire/actions/runs/8838071917

radical commented 2 weeks ago

Should the policy being followed here be documented somewhere for future reference?

You mean in a .md file in the repo? Would there be an advantage to that over just referencing this PR and corresponding issue #3933?

That issue would get closed eventually though, right? If we follow https://github.com/dotnet/aspire/issues/2276 and create new issues for next releases to track the work, as suggested by @mitchdenny, then this PR+3933 could be referenced in that, so anyone looking at updating the tags would be able to see what was done earlier, and why.

eerhardt commented 2 weeks ago

That issue would get closed eventually though, right?

Even if it is closed, it can still be referenced as "this is the policy we use".