Use standardizedVersioning from vscode-engineering for pre-release version numbers (#1441)

## 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
<img width="858" height="582" alt="image"
src="https://github.com/user-attachments/assets/d7790618-0ce7-4ee9-b885-e63ca47264ce"
/>
while vscode shows
<img width="625" height="144" alt="image"
src="https://github.com/user-attachments/assets/2c9450cd-92b2-4c75-a882-2f777a32291d"
/>


## What does `standardizedVersioning` do?

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

```yaml
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.

Author: StellaHuang95

build/azure-pipeline.pre-release.yml

@@ -83,7 +83,7 @@ extends:
         displayName: Update telemetry in package.json
 
       - script: python ./build/update_ext_version.py --for-publishing
-        displayName: Update build number
+        displayName: Validate version number
 
       - bash: |
           mkdir -p $(Build.SourcesDirectory)/python-env-tools/bin

build/test_update_ext_version.py

@@ -9,10 +9,6 @@
 
 TEST_DATETIME = "2022-03-14 01:23:45"
 
-# The build ID is calculated via:
-#     "1" + datetime.datetime.strptime(TEST_DATETIME,"%Y-%m-%d %H:%M:%S").strftime('%j%H%M')
-EXPECTED_BUILD_ID = "10730123"
-
 
 def create_package_json(directory, version):
     """Create `package.json` in `directory` with a specified version of `version`."""
@@ -71,7 +67,7 @@ def test_invalid_args(tmp_path, version, args):
             ["--build-id", "999999999999"],
             ("1", "1", "999999999999", "rc"),
         ),
-        ("1.1.0-rc", [], ("1", "1", EXPECTED_BUILD_ID, "rc")),
+        ("1.1.0-rc", [], ("1", "1", "0", "rc")),
         (
             "1.0.0-rc",
             ["--release"],
@@ -80,7 +76,7 @@ def test_invalid_args(tmp_path, version, args):
         (
             "1.1.0-rc",
             ["--for-publishing"],
-            ("1", "1", EXPECTED_BUILD_ID, ""),
+            ("1", "1", "0", ""),
         ),
         (
             "1.0.0-rc",
@@ -95,7 +91,7 @@ def test_invalid_args(tmp_path, version, args):
         (
             "1.1.0-rc",
             [],
-            ("1", "1", EXPECTED_BUILD_ID, "rc"),
+            ("1", "1", "0", "rc"),
         ),
     ],
 )

build/update_ext_version.py

@@ -79,6 +79,18 @@ def main(package_json: pathlib.Path, argv: Sequence[str]) -> None:
         )
 
     print(f"Updating build FROM: {package['version']}")
+
+    # Pre-release without --build-id: version is managed by the CI template
+    # (standardizedVersioning). Just strip suffix if publishing.
+    if not args.release and not args.build_id:
+        if args.for_publishing and len(suffix):
+            package["version"] = ".".join((major, minor, micro))
+        print(f"Updating build TO: {package['version']}")
+        package_json.write_text(
+            json.dumps(package, indent=4, ensure_ascii=False) + "\n", encoding="utf-8"
+        )
+        return
+
     if args.build_id:
         # If build id is provided it should fall within the 0-INT32 max range
         # that the max allowed value for publishing to the Marketplace.
@@ -88,9 +100,6 @@ def main(package_json: pathlib.Path, argv: Sequence[str]) -> None:
         package["version"] = ".".join((major, minor, str(args.build_id)))
     elif args.release:
         package["version"] = ".".join((major, minor, micro))
-    else:
-        # micro version only updated for pre-release.
-        package["version"] = ".".join((major, minor, micro_build_number()))
 
     if not args.for_publishing and not args.release and len(suffix):
         package["version"] += "-" + suffix