Separate release of development and production artifacts

MR: Pending

Description

As a VSCode maintainer, I want to publish development artifacts produced by merge requests that upgrade the VSCode Fork in the package registry, so that integration testing with Workspaces is easier.

Currently, all the packages uploaded to the VSCode Fork project's package registry are identified as development packages even if these packages are used in production. We need to distinguish the packages used in production by using a different naming nomenclature.

Context

The workspaces-tools project generates a Docker container image that is used by Remote development Workspaces to initialize and start VSCode Server. This project depends on the build artifacts produced by VSCode Fork repository. If we are upgrading VSCode Fork to a newer version of the VSCode upstream project, we need to test how the new version integrates with Workspaces.

To run this test, we need to produce a development image of workspaces-tools, that in turn, uses a development artifact of the VSCode Fork. Currently, in the VSCode Fork package registry, we only publish packages that are tagged as dev releases. We need to make the CI job that publishes this packages available in Merge Requests. We also need to differentiate the development packages produced by Merge Requests from the production packages produced when releasing a new production version.

Acceptance Criteria

• Production packages are not identified as dev packages. The tag version should be:
  • {{vscode-version}}-{{gitlab-production-version-release}}. For example: 1.89.1-0.1.0
• Development packages use the following format to specify their versions:
  • {{vscode-version}}-dev-{{timestamp}}. For example 1.89.1-dev-20240718125225