Mark mainline releases as GitHub pre-releases to improve Renovate-based upgrade automation #21654
Replies: 3 comments
-
|
Or if there's a recommeded approach for automated consumers to reliably select stable-only versions? |
Beta Was this translation helpful? Give feedback.
-
|
It would be inaccurate to describe our mainline releases as pre-releases. They are "stable" releases in that they can be used without the usual caveats of pre-releases, but we only promote them to stable once they've had a month in production. Given that we have this stable cadence, you might consider using https://docs.renovatebot.com/key-concepts/minimum-release-age/ and set it to ~30 days. Hope that helps. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @dannykopping, Thanks for the response and the minimum release age works for us! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Coder team — we use Renovate to automate upgrading the Coder version we deploy, and Renovate relies on GitHub release metadata to determine which versions are eligible.
Today, some “mainline” releases appear to be published as normal GitHub releases (not marked pre-release). Renovate treats those as stable and will propose upgrading to them automatically.
Could you mark non-stable/mainline releases as GitHub pre-releases, and keep the stable/LTS line as normal releases (e.g., the version you intend users to upgrade to by default, such as the release GitHub labels “Latest” stable)?
This would make “stable vs non-stable” machine-readable for automation tools and prevent unintended upgrades.
Thanks for considering.
Beta Was this translation helpful? Give feedback.
All reactions