RFC: `rover update`

[EverlastingBugstopper]

I'm proposing that we add a rover update that automatically updates the binary to the latest version. There are a few decisions to be made about its behavior that I'll outline below.

got some pseudocode here for what i think a good behavior pattern would be for this command.

1) default rover update behavior

// this will allow us to use `<` and `>` when comparing versions
use semver::Version;

let current_path = env::current_exe();
let current_version = Version::parse(env!(CARGO_PKG_VERSION));
let is_this_beta = is_version_beta(current_version);
let (latest_stable_version, latest_beta_version): (Version, Version) = get_latest_versions();
let latest_latest_version = if latest_stable_version > latest_beta_version {
  latest_stable_version.clone()
} else {
  latest_beta_version.clone()
};

if is_this_beta && latest_latest_version > current_version {
  update_exe(&current_path, latest_latest_version)
} else if is_this_beta {
  Err(anyhow!("You are currently running the latest version!"))
} else if !is_this_beta && latest_stable_version > current_version {
  update_exe(&current_path, latest_stable_version);
} else if !is_this_beta && latest_beta_version > current_version {
  Err(anyhow!("You are currently running the latest stable version. You can rerun this command with the `--beta` flag to update to version {}", latest_beta_version))
}

2) rover update --beta would look very similar to the above except it would never update to a stable release, instead always trying to update to the latest stable release and returning an error if it couldn't find anything newer

3) rover update --version v1.0.0 (equivalent to --version 1.0.0 or at least letting you know to prefix with a v) would let you install a specific version of rover and error if it could not find that version

4) rover update list would list all of the available releases to update to

the update_exe fn from above is pretty much implemented already in binstall so the work here is primarily around deciding if the default behavior i've lined out is OK in addition to some GitHub API queries.

[lrlna]

I am wondering if we should model this API after rustup update. It works a little bit differently than what you proposed (usage-wise), but has the same idea. The way I see us have this feature is like so:

1. rover update: updates to latest available version based on your current release type. If your current version is 1.0.0.beta1, update to 1.0.0.beta2. If you're on 1.0.0, update to the 1.1.0. If you're on a release candidate, update to next available release candidate.
2. rover update <release_type>. Update to the latest version of a release type. So
   • rover update stable for a stable update
   • rover update beta for a beta update
   • rover update 0.2.3 for a specific version, and finally
   • rover update release_candidate if we chose to support release candidate updates as well.

How would you feel about the above tweaks?

I really like the idea of rover update list, btw! That one is a keeper.

[EverlastingBugstopper]

love it. i think that approach is much better!

[lrlna]

A note: this flow should perhaps also include 'install from a commit sha' flow. But for this we can do point people to checkout the commit and run cargo run -- install on that commit/branch.