feat: Support self-update

[l205306]

Feature description

Idea is inspired by the update mechanism used in yt-dlp, which provides a simple CLI command to check and update to the latest release.

yt-dlp.exe -U

Current version: stable@2026.02.21 from yt-dlp/yt-dlp
Latest version: stable@2026.03.03 from yt-dlp/yt-dlp
Current Build Hash: 72a91fe064d5758c976e94f877c24369477dd3e395614b5b270dd5400a035ffa
Updating to stable@2026.03.03 from yt-dlp/yt-dlp ...
Updated yt-dlp to stable@2026.03.03 from yt-dlp/yt-dlp

Motivation

Currently, updating the CLI requires manually downloading the latest release from GitHub. It would be helpful if the CLI supported a built-in update command so it can update directly from the terminal.

Example option / flag:
-U --pre-release
-U --stable

Acknowledgements

• I have checked all open and closed feature requests and this is not a duplicate.
• I have chosen an appropriate title.

[LisoUseInAIKyrios]

An app running from a jar file cannot overwrite the jar it's running from, so self updating isn't a one click affair unless it downloads a different cli jar.

Maybe CLI can simply check if it's outdated and print a message. The update check can be to a static file here on GitHub (gradle property file?), and CLI always checks because it's cheap and quick. If network doesn't work then silently ignore the check.

[prateek-who]

This is an issue that I have wanted to fix aswell. What if, just like you said, we print a message saying the cli is outdated.
We could also add a sub-command I guess, which downloads the newer stable/ prerelease version to the same directory and once that is done, it could print a message saying:
Please close this window. I'll catch you in $filename

That way we the app won't try to overwrite itself and we'll also give the user the new cli. How does this sound?

[LisoUseInAIKyrios]

I'm kind of indifferent if it should download the update to the same directory (and effectively duplicate CLI), or if it should only check and print a message if outdated.

I kind of prefer just checking and printing a message because it doesn't add any new commands to CLI, and the user already knows how to download CLI because they did that to begin with.

[prateek-who]

That seems simple and good enough. Do we run this before any subcommand runs when a cli is outdated? Or when do we run this check?

[LisoUseInAIKyrios]

It can run when CLI is launched with patch command, and checks immediately.

It could run on a background thread that prints to the console on its own, so CLI isn't delayed by a slow network. If there is any network errors then silently ignore them.

[l205306]

This is an issue that I have wanted to fix aswell. What if, just like you said, we print a message saying the cli is outdated.
We could also add a sub-command I guess, which downloads the newer stable/ prerelease version to the same directory and once that is done, it could print a message saying:
Please close this window. I'll catch you in $filename

That way we the app won't try to overwrite itself and we'll also give the user the new cli. How does this sound?

It's fine for me if download new CLI and delete old CLI manually.

[prateek-who]

For now, I guess we'll go with the warning approach. Maybe in the future we implement the download logic too.