Conversation
|
| Filename | Overview |
|---|---|
| .release-please-manifest.json | Bumps the cli package version from 0.1.0 to 0.1.1, consistent with the rest of the release. |
| CHANGELOG.md | Prepends the 0.1.0 release block; the comparison URL v0.1.0...v0.1.0 is self-referential (known Release Please first-release quirk) and will show an empty diff on GitHub. |
| cli/CHANGELOG.md | New changelog file for @gitpulse/cli; documents the 0.1.1 release with its single feature entry and a correct v0.1.0...v0.1.1 comparison URL. |
| cli/package.json | Version bumped from 0.1.0 to 0.1.1, aligned with the manifest and changelog. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Release Please Bot] --> B[Bump cli/package.json\n0.1.0 → 0.1.1]
A --> C[Update .release-please-manifest.json\ncli: 0.1.0 → 0.1.1]
A --> D[Prepend 0.1.0 block to CHANGELOG.md]
A --> E[Create cli/CHANGELOG.md\nv0.1.0 → v0.1.1]
D --> F[⚠️ Self-referential URL\ncompare/v0.1.0...v0.1.0\nshows empty diff on GitHub]
E --> G[✅ Correct comparison URL\ncompare/v0.1.0...v0.1.1]
Reviews (1): Last reviewed commit: "chore: release main" | Re-trigger Greptile
| @@ -1,5 +1,19 @@ | |||
| # Changelog | |||
|
|
|||
| ## [0.1.0](https://github.com/znat/gitpulse/compare/v0.1.0...v0.1.0) (2026-05-04) | |||
There was a problem hiding this comment.
Self-referential comparison URL for first release
The comparison link compare/v0.1.0...v0.1.0 points to the same ref on both sides, so it will always render as an empty diff on GitHub. For a first-ever release there is no earlier tag to compare against — Release Please is known to generate this incorrect URL in that case. The link should ideally point to the tag itself (e.g. releases/tag/v0.1.0) or be omitted.
The release-please run after merging #27 failed because of a duplicate-tag collision: the root package's "release-as": "0.1.0" pin combined with the linked-versions plugin made both packages target tag v0.1.0, which already existed from a prior manual release. Result: GH release creation failed, no v0.1.1 tag was created, no npm publish happened — but the manifest got bumped to cli: 0.1.1 and PR #27's label flipped to autorelease: tagged. Rolling back the half-applied state so release-please can compute the release fresh on its next run: - cli/package.json: 0.1.1 → 0.1.0 (the bumped version was never tagged or published, so reverting is safe). - .release-please-manifest.json: cli back to 0.1.0. - cli/CHANGELOG.md: deleted (was just created with a 0.1.1 entry that never shipped; release-please will recreate on next release). - CHANGELOG.md: removed the bogus duplicate "0.1.0" header release-please added with the broken compare/v0.1.0...v0.1.0 link. - release-please-config.json: removed "release-as": "0.1.0" from the root package — it was the original cause of the collision and is no longer needed (root is already at 0.1.0). Next push triggers release-please. With the pin gone and linked-versions in place, both packages will compute to 0.1.1, the v0.1.1 tag is fresh, and the publish-cli OIDC pipeline runs end-to-end. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
🤖 I have created a release beep boop
0.1.0
0.1.0 (2026-05-04)
Features
Bug Fixes
0.1.1
0.1.1 (2026-05-04)
Features
This PR was generated with Release Please. See documentation.