Revert "Merge branch '3.0' into fasttrack/3.0"

This reverts commit 61eaa8e, reversing
changes made to 23018a8.

Author: jslobodzian

.github/workflows/check-rendered-specs-stub.yml

@@ -1,25 +1,25 @@
 # Stub workflow — A copy of this workflow must live on the default branch (3.0) so that the
 # pull_request_target event can trigger it with access to GITHUB_TOKEN (pull-requests: write).
-# It delegates all real work to the reusable template on 4.0.
+# It delegates all real work to the reusable template on tomls/base/main.
 #
 # This two-stage design lets fork PRs trigger the check safely: the stub runs in the
 # context of the default branch (with write token), but the reusable workflow checks out
 # the PR's data files (TOML configs, specs) into a separate directory — never mixing
 # untrusted code with execution context.
 #
 # The stub must exist on the default branch because pull_request_target always runs
-# workflows from there. The reusable workflow on 4.0 has the actual scripts,
+# workflows from there. The reusable workflow on tomls/base/main has the actual scripts,
 # container setup, and rendering logic.
 name: Check Rendered Specs
 
 # pull_request_target gives us a GITHUB_TOKEN with pull-requests: write even for fork PRs.
 # The stub itself runs NO code from the PR — it only delegates to a trusted reusable
-# workflow pinned to 4.0, which checks out PR data (not code) into an
+# workflow pinned to tomls/base/main, which checks out PR data (not code) into an
 # isolated subdirectory.
 on: # zizmor: ignore[dangerous-triggers]
   pull_request_target:
     branches:
-      - "4.0"
+      - tomls/base/main
 
 permissions: {}
 
@@ -32,13 +32,12 @@ jobs:
     # Prevent forks from running a stale/vulnerable copy of this stub with Actions enabled
     if: github.repository == 'microsoft/azurelinux'
     # Intentionally branch-pinned so the reusable workflow picks up updates automatically.
-    uses: microsoft/azurelinux/.github/workflows/check-rendered-specs.yml@4.0 # zizmor: ignore[unpinned-uses]
+    uses: microsoft/azurelinux/.github/workflows/check-rendered-specs.yml@tomls/base/main # zizmor: ignore[unpinned-uses]
     permissions:
       contents: read
       pull-requests: write # Post/update/delete drift comments on PRs
     with:
       pr-head-sha: ${{ github.event.pull_request.head.sha }}
       pr-head-repo: ${{ github.event.pull_request.head.repo.full_name }}
-      pr-base-sha: ${{ github.event.pull_request.base.sha }}
       pr-number: ${{ github.event.pull_request.number }}
       repo: ${{ github.repository }}

.github/workflows/spec-review-stub.yml

@@ -1,6 +1,6 @@
 # Stub workflow — A copy of this workflow must live on the default branch (3.0) so that the pull_request_target
 # event can trigger it with access to secrets. It then delegates all real work to the reusable template on
-# 4.0, which has the scripts, prompts, and agent definitions.
+# tomls/base/main, which has the scripts, prompts, and agent definitions.
 #
 # This two-stage design lets fork PRs trigger the review safely: the stub runs in the
 # context of the default branch (with secret access), but the template checks out only
@@ -14,17 +14,17 @@ name: Spec Review
 
 # pull_request_target is required here: we need secret access (COPILOT_TOKEN) to run the
 # spec review agent on fork PRs. The stub itself runs NO code from the PR — it only
-# delegates to a trusted reusable workflow pinned to 4.0, which sparse-checks
+# delegates to a trusted reusable workflow pinned to tomls/base/main, which sparse-checks
 # out only .spec data files (never executable code) from the PR head.
 on: # zizmor: ignore[dangerous-triggers]
   pull_request_target:
     # Only trigger on PRs targeting the toml base branch which modify .spec files. We do
     # not want to affect PRs targeting other branches.
 
     branches:
-      - "4.0"
+      - tomls/base/main
     paths:
-      - "**/*.spec"
+      - '**/*.spec'
 
 permissions: {}
 
@@ -38,7 +38,7 @@ jobs:
     if: github.repository == 'microsoft/azurelinux'
     # Intentionally branch-pinned to our own repo so the
     # reusable workflow picks up prompt/script/agent updates automatically.
-    uses: microsoft/azurelinux/.github/workflows/spec-review.yml@4.0 # zizmor: ignore[unpinned-uses]
+    uses: microsoft/azurelinux/.github/workflows/spec-review.yml@tomls/base/main # zizmor: ignore[unpinned-uses]
     permissions:
       contents: read
       pull-requests: write # Post review comments and inline annotations on PRs
@@ -47,6 +47,6 @@ jobs:
       pr-head-repo: ${{ github.event.pull_request.head.repo.full_name }}
       pr-number: ${{ github.event.pull_request.number }}
       repo: ${{ github.repository }}
-      scripts-ref: 4.0
+      scripts-ref: tomls/base/main
     secrets:
       COPILOT_TOKEN: ${{ secrets.COPILOT_TOKEN }}

CONTRIBUTING.md

@@ -95,7 +95,7 @@ We welcome documentation improvements. See [toolkit/docs](toolkit/docs) for the
 
 ## Pull Request Guidelines
 
-Please direct pull requests to the desired development branch. Development changes to `3.0` should target `3.0-dev`. `2.0` and `1.0` are deprecated and should not be used.
+Please direct pull requests to the desired development branch. Development changes to `3.0` should target `3.0-dev`. Development changes to `2.0` should target `main`. `1.0` is deprecated and should not be used.
 
 ### Branch structure
 
@@ -108,6 +108,13 @@ An overview of how the branches are structured can be seen below
 |3.0-preview   |Tag           |No       |No         | Publishing in progress
 |3.0-stable    |Tag           |No       |Yes        | Last published release
 
+| Git Ref      | Branch / Tag | For PRs | Published | Notes
+|:-------------|:-------------|:--------|:----------|:------------
+|main          |Branch        |Yes      |No         | **Primary development branch**
+|2.0           |Branch        |No       |Yes - eventually | Staging branch for publishing
+|2.0-preview   |Tag           |No       |No         | Publishing in progress
+|2.0-stable    |Tag           |No       |Yes        | Last published release
+
 ### PR Titles
 
 PR titles should start with an action
@@ -127,7 +134,7 @@ Please avoid titles such as
 ```bash
 - package: <whatever you did to the package>
 - CVE-XXXX-YYYY (leaving off what package was patched or upgraded)
-- [3.0] (prefixing with branch or other information)
+- [2.0] (prefixing with branch or other information)
 ```
 
 ### PR Checklist