|
| 1 | +--- |
| 2 | +name: prepare-release |
| 3 | +description: Prepare a release for the Azure App Configuration JavaScript Provider. Use when user mentions release preparation, version bump, creating merge PRs, preview release, or stable release for this project. |
| 4 | +--- |
| 5 | + |
| 6 | +# Prepare Release |
| 7 | + |
| 8 | +This skill automates the release preparation workflow for the [Azure App Configuration JavaScript Provider](https://github.com/Azure/AppConfiguration-JavaScriptProvider) project. |
| 9 | + |
| 10 | +## When to Use This Skill |
| 11 | + |
| 12 | +Use this skill when you need to: |
| 13 | +- Bump the package version for a new stable or preview release |
| 14 | +- Create merge PRs to sync branches (main → preview, main → release/stable, preview → release) |
| 15 | +- Prepare all the PRs needed before publishing a new release |
| 16 | +- Resolve merge conflicts between main and preview branches |
| 17 | + |
| 18 | +## Background |
| 19 | + |
| 20 | +### Repository Information |
| 21 | +- **GitHub Repo**: https://github.com/Azure/AppConfiguration-JavaScriptProvider |
| 22 | +- **Package Name**: `@azure/app-configuration-provider` |
| 23 | + |
| 24 | +### Branch Structure |
| 25 | +- `main` – primary development branch for stable releases |
| 26 | +- `preview` – development branch for preview releases |
| 27 | +- `release/stable/v{major}` – release branch for stable versions (e.g., `release/stable/v2`) |
| 28 | +- `release/v{major}` – release branch for preview versions (e.g., `release/v2`) |
| 29 | + |
| 30 | +### Version Files |
| 31 | +The version must be updated in **all four locations** simultaneously: |
| 32 | +1. `src/version.ts` – line 4: `export const VERSION = "<version>";` |
| 33 | +2. `package.json` – line 3: `"version": "<version>",` |
| 34 | +3. `package-lock.json` – line 3: `"version": "<version>",` |
| 35 | +4. `package-lock.json` – line 9: `"version": "<version>",` |
| 36 | + |
| 37 | +### Version Format |
| 38 | +- **Stable**: `{major}.{minor}.{patch}` (e.g., `2.4.0`) |
| 39 | +- **Preview**: `{major}.{minor}.{patch}-preview` (e.g., `2.4.1-preview`) |
| 40 | + |
| 41 | +## Quick Start |
| 42 | + |
| 43 | +Ask the user whether this is a **stable** or **preview** release, and what the **new version number** should be. Then follow the appropriate workflow below. |
| 44 | + |
| 45 | +--- |
| 46 | + |
| 47 | +### Workflow A: Stable Release |
| 48 | + |
| 49 | +#### Step 1: Version Bump PR |
| 50 | + |
| 51 | +Create a version bump PR targeting `main`. |
| 52 | + |
| 53 | +1. Read the current version from `src/version.ts`. |
| 54 | +2. Create a new branch from `main` named `<username>/version-<new_version>` (e.g., `linglingye/version-2.4.0`). |
| 55 | +3. Update the version in all four files: |
| 56 | + - `src/version.ts` (line 4) |
| 57 | + - `package.json` (line 3) |
| 58 | + - `package-lock.json` (line 3 and line 9) |
| 59 | +4. Commit the changes with message: `version bump <new_version>`. |
| 60 | +5. Push the branch and create a PR to `main` with title: `Version bump <new_version>`. |
| 61 | + |
| 62 | +**Sample PR**: https://github.com/Azure/AppConfiguration-JavaScriptProvider/pull/277 |
| 63 | + |
| 64 | +#### Step 2: Merge Main to Release Branch |
| 65 | + |
| 66 | +After the version bump PR is merged, create a PR to merge `main` into the stable release branch. |
| 67 | + |
| 68 | +1. Determine the major version from the new version string (e.g., `2` from `2.4.0`). |
| 69 | +2. Create a PR from `main` → `release/stable/v{major}` (e.g., `release/stable/v2`). |
| 70 | +3. Title the PR: `Merge main to release/stable/v{major}`. |
| 71 | + |
| 72 | +> **Important**: Use "Merge commit" (not squash) when merging this PR to preserve commit history. |
| 73 | +
|
| 74 | +**Sample PR**: https://github.com/Azure/AppConfiguration-JavaScriptProvider/pull/268 |
| 75 | + |
| 76 | +--- |
| 77 | + |
| 78 | +### Workflow B: Preview Release |
| 79 | + |
| 80 | +#### Step 1: Merge Main to Preview (Conflict Resolution) |
| 81 | + |
| 82 | +Create a PR to merge `main` into `preview`. This will likely have conflicts. |
| 83 | + |
| 84 | +1. Fetch the latest `main` and `preview` branches. |
| 85 | +2. Create a new branch from `preview` named `<username>/resolve-conflict` (or similar). |
| 86 | +3. Merge `main` into this branch. If there are conflicts, inform the user and let them resolve manually. |
| 87 | +4. Push the branch and create a PR targeting `preview` with title: `Merge main to preview`. |
| 88 | + |
| 89 | +> **Important**: Use "Merge commit" (not squash) when merging this PR. |
| 90 | +
|
| 91 | +**Sample PR**: https://github.com/Azure/AppConfiguration-JavaScriptProvider/pull/272 |
| 92 | + |
| 93 | +#### Step 2: Version Bump PR |
| 94 | + |
| 95 | +After the merge-to-preview PR is merged, create a version bump PR targeting `preview`. |
| 96 | + |
| 97 | +1. Read the current version from `src/version.ts` on the `preview` branch. |
| 98 | +2. Create a new branch from `preview` named `<username>/version-<new_version>` (e.g., `linglingye/version-2.4.1-preview`). |
| 99 | +3. Update the version in all four files: |
| 100 | + - `src/version.ts` (line 4) |
| 101 | + - `package.json` (line 3) |
| 102 | + - `package-lock.json` (line 3 and line 9) |
| 103 | +4. Commit the changes with message: `version bump <new_version>`. |
| 104 | +5. Push the branch and create a PR to `preview` with title: `Version bump <new_version>`. |
| 105 | + |
| 106 | +#### Step 3: Merge Preview to Release Branch |
| 107 | + |
| 108 | +After the version bump PR is merged, create a PR to merge `preview` into the preview release branch. |
| 109 | + |
| 110 | +1. Determine the major version from the new version string (e.g., `2` from `2.4.1-preview`). |
| 111 | +2. Create a PR from `preview` → `release/v{major}` (e.g., `release/v2`). |
| 112 | +3. Title the PR: `Merge preview to release/v{major}`. |
| 113 | + |
| 114 | +> **Important**: Use "Merge commit" (not squash) when merging this PR. |
| 115 | +
|
| 116 | +**Sample PR**: https://github.com/Azure/AppConfiguration-JavaScriptProvider/pull/274 |
| 117 | + |
| 118 | +--- |
| 119 | + |
| 120 | +## Review Checklist |
| 121 | + |
| 122 | +Each PR should be reviewed with the following checks: |
| 123 | +- [ ] Version is updated consistently across all 3 files |
| 124 | +- [ ] No unintended file changes are included |
| 125 | +- [ ] Merge PRs use **merge commit** strategy (not squash) |
| 126 | +- [ ] Branch names follow the naming conventions |
| 127 | +- [ ] All CI checks pass |
0 commit comments