Use standardizedVersioning from vscode-engineering for pre-release version numbers

[StellaHuang95]

Summary

This PR stops update_ext_version.py from overriding the pre-release version number and instead lets the vscode-engineering shared pipeline template handle it via the standardizedVersioning flag (which was already enabled but being overriden).

Why change the versioning?

Problem 1: Poor readability

The old pre-release version format was 1.27.10931010, computed as 1 + Julian day (093) + hour (10) + minute (10). Looking at 1.27.10931010, there's no easy way to tell when it was built. You'd have to reverse-engineer the Julian day and time to figure out it means "April 3, 10:10 AM UTC".

Problem 2: Different platforms got different version numbers

The pre-release pipeline builds 10 platform-specific packages (win32-x64, darwin-arm64, linux-x64, etc.) in parallel. Each platform ran update_ext_version.py independently, and because the script uses the current time (down to the minute), each platform ended up with a slightly different version:

1.27.10931008  ← linux-x64 finished at 10:08
1.27.10931009  ← darwin-arm64 finished at 10:09
1.27.10931010  ← win32-x64 finished at 10:10

In VS Code, users only see their own platform's version, so this wasn't visually obvious — but the Marketplace version history showed multiple entries per day, which was confusing.

For example, marketplace shows

while vscode shows

What does standardizedVersioning do?

The flag is already set in our pre-release pipeline (azure-pipeline.pre-release.yml line 32):

standardizedVersioning: true

When this flag is true and it's a pre-release build, the vscode-engineering template runs a step called modify-extension-version.yml before our buildSteps. See https://github.com/microsoft/vscode-engineering/blob/main/azure-pipelines/extension/templates/steps/modify-extension-version.yml for what it does.

This runs once per platform job, but $(Build.BuildNumber) is the same for all jobs in a pipeline run, so every platform gets the identical version.

Example versions under the new scheme

Scenario	Version
First build on April 6, 2026	1.27.2026040601
Second build same day (manual re-trigger)	1.27.2026040602
Build on April 7	1.27.2026040701

Why this is better

• Readable — 1.27.2026040601 clearly means "April 6, 2026, build 1"
• Consistent — all 10 platforms share the exact same version
• Same-day safe — the .Rev suffix from Azure DevOps handles re-triggers
• Always increasing — 2026040601 > 13652359 (old max), so new versions always sort ahead of old ones on the Marketplace
• Within Marketplace limits — max possible value ~2099123199 ≈ 2.1 billion, well under the uint32 max of ~4.3 billion

What changed in the code?

build/update_ext_version.py

• Added an early return for the pre-release case (no --release, no --build-id). The script now validates the even/odd minor version rule and strips any -dev/-rc suffix if --for-publishing, but does not overwrite the version set by the template.
• Removed the else branch that called micro_build_number() — this was the code that was clobbering the template's version.
• The --release and --build-id code paths are completely unchanged.

build/azure-pipeline.pre-release.yml

• Renamed the step display name from "Update build number" to "Validate version number" to reflect what it actually does now.

build/test_update_ext_version.py

• Updated test expectations: the no-args and --for-publishing (without --release or --build-id) cases now expect the original micro version to be preserved instead of being replaced with a computed timestamp.
• Removed the unused EXPECTED_BUILD_ID constant.

Stable releases are not affected

The stable pipeline (azure-pipeline.stable.yml) does not use standardizedVersioning and continues to call update_ext_version.py --release --for-publishing, which is unchanged.

[StellaHuang95]

⚠️ Before merging

Please run the pre-release pipeline on this branch with publishExtension: false (the default) to verify:

1. The modify-extension-version.yml step sets the version correctly (look for "Update the extension version in package.json" in logs)
2. All platform builds show the same version number
3. The update_ext_version.py step ("Validate version number") runs without errors and does not change the version

I don't have permission to trigger the pipeline, so I'd appreciate if someone could run this validation before merging. Do not merge until the pipeline has been tested successfully.

[karthiknadig]

There seems to be test failures. But I can do the run for you if you need

[StellaHuang95]

There seems to be test failures. But I can do the run for you if you need

The test failures should be fixed after #1442 is checked in.

Sure it would be great if you could run the pre-release pipeline on this branch with publishExtension: false to verify. I think it's https://dev.azure.com/monacotools/Monaco/_build?definitionId=614? Please run on this branch, the changes are not in main yet.

[karthiknadig]

This branch is in your fork. Can you push a copy to the origin? I just gave you write access.

[StellaHuang95]

Sure, you should be able to run pipeline from https://github.com/microsoft/vscode-python-environments/tree/version

[karthiknadig]

Works:

[StellaHuang95]

Sounds good, can you actually run the pipeline again for me?

I installed the vsix from build artifacts, was trying to do some manual testing to make sure the vsix is built properly with the changes, but was seeing the same issue as Fix refresh failure caused by JSON-RPC sending [null] params to pet binary, so just rebased against main and want to validate the pipeline with the fix in again and make sure the vsix is working alright.