stackablectl version upgrade notice

[razvan]

It would be nice if stackablectl would check for new versions and inform the user about those.

Planning

Why

We have had users reporting issues with demos, and then later finding out that they are running older versions of stackablectl which still used the main branch.

Users should be notified of updates so that they do not have to check, or end up on versions which become incompatible with SDP.

How

• Plan for how to check for new versions of stackablectl, and a way to test it.
  • Consider reporting it to STDERR
  • Consider pointing the user to release notes so they can see the benefit of upgrading.
  • Consider lack of internet connectivity
  • Consider data privacy
  • Consider RC file for allowing opt-out.
  • Append the plan to this issue
• Implement and test the check.
• Release it
• Optionally communicate this across various channels so we can get users to upgrade so they can then be notified.
• Create a new issue for next steps (to look into auto-updating the binary on command)
  eg: stackablectl version upgrade.

[lfrancke]

Thank you for the detailed issue @razvan!

I'd like the scope to be minimal. If this takes longer than one week it is too long.

These are my goals and non-goals for this ticket:

✔️ Goals

• Checks if a new version is available (yes/no)
• Report to STDERR as suggested
• Gracefully handles offline/no internet (just skip the check, no error, should not block)
• Use the GitHub releases API to get information (https://api.github.com/repos/stackabletech/stackable-cockpit/releases/latest)

❌ Non-goals:

• No release notes fetching
• No analytics/telemetry
• No auto-update capability (separate issue)

〰️ Maybe:

• Cache the result or record the last checked timestamp and only check once a week or once a day
• Opt-out mechanism

You can challenge me on the URL decision.
I though about hosting our own static file with version information (e.g. https://static.rust-lang.org/dist/channel-rust-stable.toml) but that requires us to integrate it into CI/CD and to always have it available. GitHub will not change that release API any time soon.

I estimate the goals mentioned above should not take more than 1-2 days to implement. If that is the case I'm happy to spend another max 1-2 days on the "Maybe" goals. If you think my estimate is off please tell me before you start work.

If you agree with my "refinement" you're welcome to remove the label and start implementation. If not let me know.