I figured it might be a good idea to have an umbrella topic for the merger while it's under way.
@matklad I'm porting the update and release id/tag portions of the original code and would like to detach installed RA version from the extension version itself (and thus having to implement auto-update for 'stable' releases). The way I set up stuff before is so the user can specify
releaseTag that will be downloaded. I propose that we can also specify
stable (analogously to
nightly) which will fetch the latest non-nightly release and which will be also gated behind some internal github poll timeout (e.g. 1hr like now, for nightly). Does that sound good?
So in addition to specifying e.g.
2020-08-24 we can also specify
stable which should be auto-updating and try to pull the latest release from GH from time to time :smile:
Let me think for a moment, that's probably the most tricky bit...
FWIW, I think to just merge the extensions, it's fine to start with an explicitely specified path, and tackle auto-update in a separate PR
IE, I wouldn't find it unreasonable to say "hey, rust-lang/rust extension just uses the version from
the thing is, just merging as-is would lose the auto-update feature for RA as it is now
because we don't continuously release vsix extensions with bumped release versions from package.json that are later used to fetch 'latest' RA
and I'd prefer to tackle this now rather than have a period of time where we temporarily change the current release model for the extension
I mean, we should fix this before we say to folks "hey, switch to rust-lang/rust extension", but we don't have to do this in the initial PR
@matklad oh right I forgot about RA being shipped with rustup :face_palm:
let me think
where does it install the binary? to
it = rustup? I am not sure if the shim is already in place.
But we can ask rustup folks to do a minor release, and than yeah, it will be there
we can do that separately
okay then, let's leave the auto updates for later
Users can already set explicit releaseTag or path to the server binary
So, the original motivation behind tying the two versions together was to avoid doing HTTP requests without explicit user's consent.
That is, we were able to leverage marketplace's auto-update function. But just looking, locally, at the version of the extension and the version of the binary, we could say if we need to auto-update.
As opposed to querying GH API just to figure out if we need to update.
We definitely want separate release schedules for server and extension, at least for the time being. So, it seems like there's no other way than to implement auto-update on stable. And of course the question of defaults araises:
These are valid points, thanks for bringing up the original motivation. While I appreciate not doing the HTTP requests without user consent, I don't think needs as much attention:
However, if we also account for
rustup as another means of auto-updating the server binary, then we might need to rethink on how to best tackle that and let the user select the release model they want to follow.
Let's leave this for now, then :) We can implement a simple auto-update after this PR; this should give us more time to rethink our possible options
rustup there should be no auto update. rust-analyzer is bound to a specific rust toolchain version. I don't think anybody wants an editor extension to suddenly update rustc while building a project.