Closed iamsauravsharma closed 5 months ago
@roshkhatri @hpatro Can you guys take a look at this?
On another thought and discussion with @hpatro we should probably just set the 7.2 as latest
and not include 7
tag as someone might just want 7 to be as 7.0 and not bump up to 7.2. Not that we have 7.0 but just for an example.
@roshkhatri With semantic versioning, if you specific 7, you would expect the latest version of 7.x.y according to semantic versioning. Which in this case would be 7.2, so I think we should release a 7.
@roshkhatri With semantic versioning, if you specific 7, you would expect the latest version of 7.x.y according to semantic versioning. Which in this case would be 7.2, so I think we should release a 7.
Does this get called out in SemVer? From what I read here https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions is it to have major.minor.patch to be a valid semver.
That's not exactly what I meant, I was saying that if you put in 7, I would expect it to be most recent version of 7 (ordered by semantic versioning. Where 7.2.5 is later than 7.0.99)
@roshkhatri @hpatro I think your suggestion will cause more confusion than actually helping. Lots of containers, even Redis, use X
to represent X.Y.Z
or X.Y
which is the latest release of X
. I don't think there is many widely used container that follows your suggestion, so there will be more confusion
Since it is de facto standard so as a user I would expect 7
will pull recent version of 7
instead of 7.0.X
Did take a look at some other popular docker containers
Bitnami Redis (https://hub.docker.com/r/bitnami/redis/tags) uses major.minor and major.minor.patch version releases and doesn't have a major version only tag.
However, NodeJS/Postgres/OpenSearch/Alpine, all support a major version only tag. With these many data point(s) I guess it's a standard practice.
Create aliases for 7.2