VS Code extension can do
[pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions).
This would make it easier to test unreleased version of the extension
(thanks @ds300 [for the
suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351))
Tried the pre-release option manually, to see how it works:
https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334
There's a drawback in that we need to update version even for
pre-releases as they do not support other versioning schemes atm. I
decided to go with patch versions for pre-releases and minor versions
for regular releases. Feels like a better UX than having a really high
patch number due to bumping it on every PR.
> We only support major.minor.patch for extension versions, semver
pre-release tags are not supported. So, if you publish a
major.minor.patch-tag release to the Marketplace, it will be treated as
major.minor.patch, and the tag will be ignored. Versions must be
different between pre-release and regular releases. That is, if 1.2.3 is
uploaded as a pre-release, the next regular release must be uploaded
with a distinct version, such as 1.2.4. Full semver support will be
available in the future.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [x] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Release Notes
- Release a pre-release when we merge changes to main.
When pushing to production branch we now also package and publish a new
version of the VS Code extension. We get the last version from VS Code
marketplace and update the package.json with that version. We don't
commit that to the repo though (see the discussion below).
I added `VSCE_PAT` secret (my own personal access token from the
dev.azure.com), which will expire in 1 year. This is used when running
the publish command.
Some more info here:
- [Publishing from
CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions)
- Publishing uses `VSCE_PAT` env variable
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [x] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Release Notes
- Automate publishing of the VS Code extension.
