alpha version of extension

[janpio]

Is there a way to use the alpha version of this extension, that has the same validation as the current prisma2@alpha?

[matthewmueller]

We don't currently publish alpha versions, this would be dependent on #48.

After that, I think you can do something like... vsce install prisma@alpha.

[janpio]

Why we should have this:

[janpio]

Internal Slack thread on how to "hack" an alpha version until this is implemented: https://prisma-company.slack.com/archives/CEYCG2MCN/p1585335479124100

[divyenduz]

Options

We have the following options:

1. Preview extension

Via the preview option in package.json file.

Cons: In my understanding, this is just cosmetic and adds a "Preview" to the extension page. Auto update still applies to these extensions making it a less favorable option for us as we don't want users to automatically be on the alpha.

2. Separate alpha extension (name: Prisma Alpha, slug: prisma-alpha, version: x.y.z-alpha)

This is probably the safest option for us. We can publish a new extension that is always updated to the latest alpha.

Name: Prisma Alpha
Slug: prisma-alpha
Version: Same as the prisma alpha

This is what Julia lang extension does as well.

Pros: Simpler to document
Cons: Non-trivial CI pipeline (see below)

3. Configuration in extension

This is how Python extension does that.

This can be a configuration argument to pin the current version or a UI selector like the python extension (how to select a specific version though?) or Using the installed Prisma CLI in the current project defaulting to main release channel.

Pros: Easier to switch between different Prisma projects running on different versions

4. Marketplace release channels

This probably doesn't exist yet but will be the most desirable solution once it exists microsoft/vscode#15756

I am curious to know if there is any docs available that make the command used in Matt's comment to work. I couldn't find any besides this comment, which doesn't link to any docs.

---

Implementation

Assuming that we choose option 2. Separate alpha extension, this is how we can add that to the current automation workflow:

Current workflow

1. The job gets triggered on a commit to master branch of VSCode extension repo and additionally it runs on a schedule of every 5 minutes
2. The job checks the Prisma version in VSCode extension against the latest release channel version
3. If there is a newer Prisma version release in the latest channel, the job updates the version and binary hash in VSCode extension repo and releases the extension
4. If there was a release, the job commits the changes to master

New workflow

1. A new job gets triggered on a commit to master, alpha branch of VSCode extension repo and additionally on a schedule of every 5 minutes
2. The job checks out the alpha branch
3. The job checks the Prisma version in VSCode extension against the alpha release channel version
4. If there is a newer Prisma version release in the alpha channel, the job updates the version and binary hash in VSCode extension repo and releases the alpha extension
5. If there was a release, the job commits the changes to alpha

Considerations

There is a limitation in this release workflow though, any changes to master in the VSCode extension itself will have to be manually synced with alpha branch. We can't do that in the CI as it would conflict, since, we are bumping the version/binary hash in both branches.

An alternative can be to fix the version/binary hash in VSCode extension code to (say) "auto" and rely on the CI to make the release and revert the version to "auto". This would ensure that we can merge master on alpha in the CI.

[matthewmueller]

Thanks for compiling this! I like 3. the best from a user perspective, but I think that only works if the contents of the extension aren't changing that much and all logic is deferred to a separate language-server binary

I think for now 2. is the way to go. I'm not sure if this is what you mean in the new workflow, but we could have 2 separate jobs running, one for alphas, one for releases.

[janpio]

Option 3 is a future problem, which would need considerable amount of rework.
For me Option 2 seems to do the job for now. I can easily enable and disable the latest and alpha versions to switch between them, install specific alphas etc.

[divyenduz]

I'm not sure if this is what you mean in the new workflow, but we could have 2 separate jobs running, one for alphas, one for releases.

That is what I mean yes, two jobs writing to two different branches though.

---

The only consideration regarding 2 is that whoever changes master has to manually update alpha too. Nothing else speaks against option 2.

Also, does anything speak against matching the Prisma version as the extension version too?

[janpio]

Also, does anything speak against matching the Prisma version as the extension version too?

To the contrary, there should be an issue for that. Probably makes sense to do it with this, as you will need a way to version the alpha releases.

[divyenduz]

To the contrary, there should be an issue for that. Probably makes sense to do it with this, as you will need a way to version the alpha releases.

That's why I thought about it now, instead of writing some new logic for alpha version numbers, I can just use Prisma version.

Linking the existing issue here: #93