[RELEASE] version 0.8.0

[jurgenvinju]

Preliminaries

• Every time this document says "release X" ; we mean to execute the instructions of this Wiki page: https://github.com/usethesource/rascal/wiki/How-to-make-a-release-of-a-Rascal-implemenation-project
• The current release instructions are focused on the rascal-language-servers project and the VScode extension that is included there
• If you edit this template, then please push relevant improvements to the template itself for future reference.

Pre-releasing dependent tools in unstable

First a "pre-release" of the supporting compiler/typechecker tools must be done, so we know we are releasing a consistently compiled standard library.

• [x] typepal and rascal-core compile in the continuous integration environment and no tests fail
• [x] release typepal
• [x] release rascal-core
• [x] bump typepal and rascal-core versions in rascal-maven-plugin to latest releases
• [x] release rascal-maven-plugin
• [x] bump rascal-maven-plugin dependency in rascal and rascal-lsp projects
• [x] bump typepal and rascal-core versions in rascal-lsp project
• [x] fix new errors and warnings in rascal and rascal-lsp project

Manual version checks

• [x] Continuous Integration runs all unit and integration tests and fails no test
• [x] Maximum number of compiler warnings are resolved
• [x] Version numbers are verified manually

Manual feature tests

• [x] Build VScode extension locally download and install latest .vsix file in VScode for testing purposes

The list below was copied from the rascal-eclipse release; have to adapt while we go:

• [x] Open a Rascal REPL using the CMD+P start-rascal-terminal command (without a project)
• [x] Manually create a new Rascal project, with src folder, META-INF/RASCAL.MF file with Required-Libraries: |lib://rascal-lsp|
• [x] Can edit a new Rascal file in the Rascal project
• [x] Save on Rascal file triggers type-checker, errors visible
• [x] Rascal outline works
• [x] Clicking links in REPL opens editors and websites
• [x] rascal>1 + 1 on the REPL
• [x] import IO; println("Hello Rascal!");
• [x] in editor, click on use of name jumps to definition
• [x] jump-to-definition also work to libraries and inside of libraries #150
• [x] clicking in outline jumps to editor to right position
• [x] syntax highlighting in editor works
• [x] add dependency on another project by editing RASCAL.MF: Require-Libraries: |lib://otherProject|, import a module and test the type-checker as well as the interpreter for correct resolution, also test a new REPL and import a library modules from the imported library.
• [x] Run import demo::lang::pico::LanguageServer; and demo::lang::pico::LanguageServer::main(); and test the editor of some example pico files:
  • [x] pico syntax highlighting
  • [x] pico parse errors
  • [x] pico jump-to-definition
  • [x] pico code lenses with command (Rename variables a to b)
• [x] try :edit demo::lang::pico::LanguageServer #151

Actual release

• [x] write release notes in README.md (used on the marketplace pages)
• [x] release rascal project (when resolving SNAPSHOT dependencies choose the right versions of vallang etc, and make sure to bump the new rascal SNAPSHOT release one minor version)
• [x] release rascal-language-servers project (take care to choose the right release versions of typepal and rascal-core you release earlier and choose their new SNAPSHOT dependencies to the latest)
  • [x] Set the proper version inside rascal-lsp/pom.xml (in most cases, remove `-SNAPSHOT)
  • [x] Set proper version information in rascal-vscode-extension/package.json (in most cases by removing -head from the current version)
  • [x] git commit -am "[release] set release version"
  • [x] git tag vNewVersion
  • [x] git tag rascal-lsp-NewVersion (fill the rascal-lsp version that is released here, so for example rascal-lsp-2.12.0)
  • [x] Set next version in package.json with head suffix; e.g. 0.2.0-head
  • [x] Set next version in pom.xml with snapshot suffix; e.g. 2.2.0-SNAPSHOT
  • [x] git commit -am "[release] prepare for next release
  • [x] git push
  • [x] git push --tags
• [x] test the released vsix file from the VScode marketplace

[DavyLandman]

Good idea, I would like to get a fix in for #263 where the commands are not working correctly if in an embedded mode.

[jurgenvinju]

Has that issue been reproduced?

[DavyLandman]

I think I know what's going wrong there, I need to find some time to get to it. But maybe that's better for a 0.8.1 release, as I don't think I'll get to it this week.

[jurgenvinju]

I'm pretty sure I won't make the release this week. It would be a miracle.

[DavyLandman]

I want to propose we do not release vscode with -RC dependencies in rascal-lsp. What's your opinion on that?

My feeling is, RC is nice for testing out integrations, but before we do an actual public release, we should make sure our dependencies are also non RC, since we tested out their integration.

[jurgenvinju]

O you mean inside! Yes indeed, like you said; we want to have the bootstrap complete. But to get that, we first need to test with RC dependencies, otherwise every new bug will have to lead to 2 new releases (one RC and one not) of the rascal project, or the vallang project, or both. That's just too much for my brain. Every RC release of Rascal also has to be "bootstrapped out" of rascal-maven-plugin before we release the lsp and the eclipse versions.

[DavyLandman]

Then maybe they shouldn't be called RCs? Since RC normally signals: don't take dependencies on this, this is for integration testing, once we agree everything in these RCs is working as intended, we'll release a actual version.

[jurgenvinju]

are we not integration testing? I'm confused now.

[DavyLandman]

We are :) I thought you meant that switching to non-RC would be to hard to do right before we actually release this VS Code 0.8.0. Otherwise I didn't understand your comment correctly.

To clarify, while these tests are running, I think RCs are the best approach. Once we agree it's all good, then we move to non-RC.

[jurgenvinju]

No that is not hard. It would be hard to switch during integration testing, because then we'd get a complex yoyo effect.

[DavyLandman]

ah yes, that would be madness ;)

[jurgenvinju]

• important to remove old .tpl files once to make the IDE features work

[jurgenvinju]

This is done. Currently running releases of all the libraries that will end up on rascal-mpl.org/doc/Packages