Publish to Open VSX on ggsql-vscode release

[georgestagg]

This GHA workflow is gated on vscode/v* repository tags, similar to the python-release.yml workflow.

[teunbrand]

Thanks George! Just for my understanding, this also is triggered whenever we do the main release right, or do we have to do a separate vscode release?

[teunbrand]

This comment is not a blocker:
Can we do the equivalent of symlinking in github so we don't have multiple versions of licences?
In addition, we may want to bump this (here and elsewhere):

Suggested change

	Copyright 2025 ggsql authors
	Copyright 2026 ggsql authors

[georgestagg]

Yeah, I think we can have symlinks, that's a good idea. I'll make a followup PR to do it after this is in.

[georgestagg]

Just for my understanding, this also is triggered whenever we do the main release right, or do we have to do a separate vscode release

If we make a main release tagged with vX.Y.Z only the installer GHA workflow will run at the moment. Separate releases with tags py/vX.Y.Z and vscode/vX.Y.Z are required to trigger the workflows for publishing to PyPI and OpenVSX respectively.

I believe the intension for now is that we can have separate release streams, potentially all with different version numbers. This could be useful if we want to bump the Python package, or the VSCode extension, to include some new changes without also having to release a new version of the core ggsql binaries.

The alternative would be that tagging vX.Y.Z triggers a new release of everything, we keep the version numbers all in sync, and any time we need to push an update for the vscode extension or Python package we just release a new version of everything.

I don't mind which of the two schemes we land on, I was just following the current Python package setup. We could ask the rest of the group for thoughts?

[teunbrand]

Thanks for elaborating! It probably needs to be discussed at some point, but that shouldn't block this PR