Repository navigation
go feature: support pseudo-versions "stable" and "oldstable" #1289
Description
Activity
Hello TheDiveO (@thediveo) ,
Thank you for raising this issue. By that convention, for devcontainer go feature (in fact for all relevant features) we are already providing the previous version with the actual version number which can be specified with the version option within go feature tag in devcontainer.json, Ref .
Kindly let me know if you feel this is really required & reason for the same.
With Regards,
KaniskaUnderstood, but I'm asking for a different use case than specific semver pinning -- the same as implemented in the Github action setup-go: you logically pin to "stable" and "oldstable" and oldstable will automatically resolve into 1.23, 1.24, ... over time without the need to update lots of devcontainer.jsons that reference the go feature. This allows for once and all, like with Github actions, to provide devs with two well-definied environments on Go stable and oldstable, automatically progressing as the Go project releases new "major" go toolchain versions each 6 months.
The GH action https://github.com/actions/setup-go has the notion of "stable" and "oldstable". This nicely supports the way the Go toolchain is supported always in versions 1.N and 1.N-1.
To my understanding, this "stable" is equivalent to "latest" in the go dev container feature. To easily test with stable and oldstable toolchain versions, I would like to propose to support also the pseudo-version "oldstable" to parallel the GH go-setup action mechanics. In this view, I propose to support also "stable" as an alias to "latest".