More continuous releases

[amiralies]

Ideally a release can happen on each master branch commit, I'm aware this can't happen for big changes like recent highlighting/code actions etc. but I think we can do releases more often than what we do atm.

For more context, I was always using the language server from master branch with neovim, doing rescript almost on daily basis and I had an stable experience.

[zth]

I'm personally also interested in at least a way to more easily use a bleeding edge/experimental version of the extension, so we can get more testing. But I'm unsure how to do this in practice.

[amiralies]

Maybe we can use https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions for this usecase

[fhammerschmidt]

Yup. Have a look at the rust-analyzer repo for inspiration.

[zth]

Ohhh, that looks great, we should definitively do that! @cristianoc do you have opinions on this?

[fhammerschmidt]

Woops, i referenced the wrong line. I meant this one.

I would tackle this issue, but first we would need to decide on when this (pre-)release action would trigger.

1. After successful master build
2. On push to a (pre-)release branch
3. Nightly/weekly
4. Other suggestions?

[zth]

I think 2 is a good option. We'll make sure to publish as often as it makes sense/is stable enough for testing. What do you think?

[fhammerschmidt]

So if we even automatically release via a release branch at some point, we would have both a release and pre-release branch beside the master branch?

But then somebody always needs to decide on whether we should release this now or not and manually trigger it. With the other options you don't even have to think about it.

I'd prefer to pre-release automatically (but do not care how), and only require manual work for main releases (where somebody needs to decide which version number to use as well as update the changelog).

[cknitt]

I fully agree with @fhammerschmidt: We should avoid manual steps for pre-releases, even if an automatic process slightly increases the chance that the user downloads a broken version. In practice, I have been working with the master builds for some time now, and did not run into any problems.

[zth]

Sounds good to me, I think master can be considered fairly stable. We also typically do quite extensive testing of feature branches, so it should remain fairly stable too.

@cristianoc @ryyppy what do you think?

[cristianoc]

Having a model which is completely automatic would be great.

[zth]

Is this something you @fhammerschmidt for example would be up for working on? Is it meaningful/possible to work on it without repo/publishing rights, etc?

[fhammerschmidt]

Just created #399 but somebody with more rights needs to finish it.

[aspeddro]

Just created #399 but somebody with more rights needs to finish it.

Will this create a release with a pinned tag? like in rust_analyzer nightly?

[fhammerschmidt]

Will this create a release with a pinned tag? like in rust_analyzer nightly?

That would mean that every merge to master will be its own tag?

But I guess having a pre-release also available from the GitHub releases page like rust-analyzer would be nice for people that don't use the marketplace.

Also we don't have a versioning scheme suitable for vscode pre-releases yet. Rust-analyzer pre-releases are always a minor version higher than the last main ones, so they are always on top of the releases page and updates in VSCode don't move them back to the main release channel.

[aspeddro]

That would mean that every merge to master will be its own tag?

Yes.

But I guess having a pre-release also available from the GitHub releases page like rust-analyzer would be nice for people that don't use the marketplace.

I wanted to test the server in vim/neovim, having a pin tag allows you to automate this.

https://github.com/rescript-lang/rescript-vscode#use-with-other-editors