Closed ricoli closed 4 years ago
Excellent suggestion. It makes sense to allow sticking to a major version with no breaking changes, but still get bugfixes and features/performance improvements
Same here. We don't want lts
since that would mean a 12-14 upgrade when lts
changes, but we do want to test on the latest 12
.
One of the companies I work with has node standards that define "always use the latest major version of node" as the feel comfortable having automatically incremented minor and patch versions but not major versions.
There's no current plans to do this. This is something we're aware of though and will be considering depending on future feedback.
There's two main reasons why don't have this currently:
15
and would point to Node.js v15.2.0. If Node.js decided to do a patch release for the v15.0 series, that version would be v15.0.2. Our system, would then update the major tag 15
to point to that release, which isn't what you would want. When we support release candidate and beta versions in the future, it makes this issue more complicated.In regards to item 2 - I think I could submit a PR for this that'd properly fetch the latest "minor.patch" for each "major" version. I think the logic would look like:
node-v.*-linux-x64.tar.xz
Two stumbling blocks, but otherwise I'd be good:
/dist/latest-v*.x
always contains only one file matching a given regex, but I suspect it does.Hi all, I've created an idea for this in the features suggestion portal for CircleCI. Please vote for this idea so that we can gauge what the demand is: https://ideas.circleci.com/images/p/re-introduce-latest-tags-for-next-gen-convenience-images
Would it be possible to also publish tags just with the major version, as currently done in circleci/node? For example,
cimg/node:10
andcimg/node:12
.