feat: add release-please for automated versioning and releases#5
Merged
Conversation
Adds release-please-action workflow + config + manifest. On every push to main, the bot scans Conventional Commits and maintains a pending Release PR with auto-generated CHANGELOG entries and version bump. Merging the Release PR creates the vX.Y.Z tag, which triggers the existing release.yml to build, verify, and npm publish. Contributors no longer hand-write CHANGELOG entries; PR titles in Conventional Commits form become the changelog. Existing CHANGELOG.md stays as the historical record and release-please appends to it. Initial manifest version is pinned to current 0.2.0-alpha.3; version bump is deferred to a future commit with a Release-As footer. CONTRIBUTING.md updated with the new workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds release-please to automate version bumps, CHANGELOG generation, git tagging, GitHub Releases, and npm publishing.
What changes for contributors
PR titles already follow Conventional Commits (
feat(sdk): ...,fix(sdk): ...). The bot reads them to compute the next SemVer bump and to generate the CHANGELOG entry. No more hand-written changeset files.What lands
release-please-config.json- single-package config,release-type: node, prerelease support withalphalabel so we keep shipping0.2.0-alpha.Nuntil aRelease-As:footer drops the suffix..release-please-manifest.json- pinned to current0.2.0-alpha.3..github/workflows/release-please.yml- runs on push tomain, opens or updates the Release PR.CONTRIBUTING.md- new "Releases" section, plus a Conventional Commits clarification on the PR rules.How it interacts with existing release.yml
release-pleaseonly creates the tag. The existingrelease.ymlalready triggers ontags: ['v*']and handles build, tarball verification, dist-tag selection, andnpm publish --provenance. No changes needed there.What I expect to happen after merge
This commit is
feat:, so release-please will see one new feat since0.2.0-alpha.3and propose a Release PR titled roughlychore(main): release langos-sdk-node 0.2.0-alpha.4. Merging that Release PR creates thev0.2.0-alpha.4tag, which triggersrelease.ymlto publish.The alpha.4 release is functionally identical to alpha.3; it just marks the point where release-please took over.
Forcing a specific next version
Documented in CONTRIBUTING.md. Add a
Release-As: <target>footer to a commit on main to override what the bot would compute (e.g., to drop the prerelease suffix at a milestone).