Floating major release tags

[mgabeler-lee-6rs]

It would be nice to have floating major release tags -- e.g. "14" and "15", so that pulling in bug fix releases doesn't require lots of editing of CI configs.

I miss this actually in many of the cimg releases, but in postgres the most.

[JalexChen]

Hi @mgabeler-lee-6rs - thanks for submitting. Putting this in the backlog right now as the images are intended to be deterministic. We'll take a look at implementing this if it makes sense across the cimg suite

[mgabeler-lee-6rs]

Please note my point that this is already done with other cimg releases. NodeJS for example has floating tags across bugfix-only updates, as does Go. The difference here, at least as I see it, is that the bugfix component for PG is the second component in the version, not the third. So PG x.y means "I don't want any bug or security fixes or any updates at all", and is equivalent to pinning to a commit hash, whereas NodeJS or Go x.y is "I want bug fixes for this feature release".

Certainly being able to pin to an exact release is good! But having to go through and edit dozens of files to take in a PG bug/security fix is unfriendly to developers, esp. since, AFAICT, there's no automation tooling available to help with this -- compare to e.g. dependabot's support for updating versions of github actions components defined in those flows.

[JalexChen]

Hi @mgabeler-lee-6rs - what you're requesting is a side effect of how postgres versions, not that this has already been implemented with other cimg releases. i can, however, see how this could be useful.

postgres releases an update roughly every quarter and this is not an immediate bugfix. i think there is certainly a better way to manage this similar to what you described with GHA and dependabot, but i think that will need to addressed later.

you mentioned that you need to edit dozens of files to account for a PG fix -- but would you be able to set this as a variable so the changes are propagated across those files?

[mgabeler-lee-6rs]

but would you be able to set this as a variable so the changes are propagated across those files

Please advise how you think this would be implemented, particularly where you think such a variable would be declared and how it would propagate. Things I've already considered:

1. YAML anchors can't be included from another file. We already use them within a single CircleCI config to reduce duplication, but they still need to be declared once per file.
2. We have more than one repo (more than a hundred I think) using CircleCI. Including variable declarations from outside the repo seems challenging, if it's even possible.

If there is a straightforward solution to these issues, I'm very interested to learn :)

[mgabeler-lee-6rs]

Cross-referencing a similar issue: CircleCI-Public/cimg-node#294

[JalexChen]

@mgabeler-lee-6rs - i don't have a full grasp of your unique situation and this was just a suggestion. if it is not feasible, then we can look for alternatives. i understand the original ask and this is something we can look into across the cimg suite, however, implementation would happen next quarter at the earliest.

if you would like to try your hand at it, the easiest way to do this would be through the gen-dockerfiles.sh script in the cimg-shared submodule

the output would look similar to what we do for clojure, which adds a docker tag statement to the latest (default) release

[jbauerrfid]

I would appreciate floating docker tags as well. When #115 gets resolved that would mean for our team to update every single microservice repo which runs Postgres tests just to update the minor version of Postgres to a fixed version.
With a floating tag the CI should pick the latest of the current major version automatically.