You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore(release): version-lock CLI to bundle for v0.2.0-beta.1 (#316)
* chore(release): version-lock CLI to bundle for v0.2.0-beta.1
Prep for the first bundle-versioned release. Aligns the CLI to the bundle
version, points the release workflow at the bundle tag, and enforces the
versioning scheme from
#27.
Signed-off-by: Kyle Hounslow <kylhouns@amazon.com>
fail "Git tag '${GITHUB_REF_NAME}' does not match package.json version '${version}'. Tag and package.json must agree — the CLI clones the stack at v<package.json version>."
How maintainers cut a release of observability-stack. Versioning follows the scheme in [RFC #27](https://github.com/opensearch-project/observability-stack/issues/27).
4
+
5
+
## Versioning
6
+
7
+
Independent bundle semver: `vMAJOR.MINOR.PATCH[-(alpha|beta|rc).N]`. Upstream component versions (OpenSearch, Data Prepper, OTel Collector, Prometheus) are pinned in `.env` and listed in the release notes, not encoded in the tag.
8
+
9
+
- Prerelease: `v0.2.0-beta.1`, `v1.0.0-rc.2`. Publishes to an npm dist-tag matching the qualifier (`alpha`/`beta`/`rc`), so bare `npx` stays on the stable `latest`.
10
+
- Stable: `v0.2.0`. Publishes to `latest`.
11
+
-`v1.0.0` is a deliberate major/GA decision (a breaking change or a GA milestone), not an automatic follow-on to the first stable.
12
+
13
+
The `release-drafter.yml` workflow rejects any tag that does not match the scheme, or whose version disagrees with `aws/cli-installer/package.json`.
14
+
15
+
## The CLI ships with the bundle
16
+
17
+
The CLI (`aws/cli-installer`, published to npm as `@opensearch-project/observability-stack`) is version-locked to the bundle. Its managed deploy clones the stack at the git tag matching its own version (`v${PKG_VERSION}`). So the CLI `package.json` version, the git tag, and the release must all agree. There is no CLI-only release path.
18
+
19
+
## Cutting a release
20
+
21
+
1. Open a PR that sets `aws/cli-installer/package.json` to the target version (e.g. `0.2.0-beta.1`). Sign commits for DCO (`git commit -s`). Get a maintainer review and merge to `main`.
22
+
2. Tag the merged commit and push it:
23
+
```
24
+
git tag v0.2.0-beta.1 <sha>
25
+
git push upstream v0.2.0-beta.1
26
+
```
27
+
The tag is the release trigger. Merging alone publishes nothing.
28
+
3. The `release-to-npm` job pauses on the `release-approval` environment. A required reviewer, who cannot be the release author, opens the workflow run and approves the deployment.
29
+
4. On approval, the workflow validates the version, runs tests, publishes the CLI to the correct npm dist-tag, and drafts the GitHub release. Fill in the release notes with the component-version matrix from `.env`.
30
+
31
+
## Promoting a prerelease to stable
32
+
33
+
Once the prerelease is validated and any fixes are merged, repeat the flow with the qualifier dropped: set `package.json` to `0.2.0`, tag `v0.2.0`, approve. It publishes to `latest`.
0 commit comments