[chenpeizhi]

Two problems with the release-please setup. The first is what #10 exposes; the second I found while checking it.

1. The baseline is wrong, so #10 would re-release 0.1.1

.release-please-manifest.json says 0.1.0. But 0.1.1 and 0.1.2 both shipped, back in 2017:

0.1.2   Bugfix release   2017-05-27
0.1.1   Bug fix release  2017-02-15
0.1.0   First release    2017-01-24

So release-please computed the next version as 0.1.1, and #10 proposes exactly that. There is no hard tag collision, because release-please tags as libcanon-v0.1.1 while the 2017 tags are bare 0.1.1 — which is arguably worse, since the clash would be silent. Two different artifacts would both be called libcanon 0.1.1, and the changelog would claim 0.1.1 was released in 2026 with a set of fixes that has nothing to do with the 2017 one.

Setting the baseline to 0.1.2 makes the next release 0.1.3, which is what it should be.

2. CMakeLists.txt has never had its version updated

release-please-config.json lists CMakeLists.txt as an extra-file of type generic. The generic updater only rewrites lines carrying an x-release-please-version annotation, and there was none. So this line had sat unchanged since 2017:

project(libcanon VERSION 0.1.0 LANGUAGES CXX)

That is not cosmetic. CMakeLists.txt feeds write_basic_package_version_file, so the stale version lands in the installed libcanon-config-version.cmake and governs find_package(libcanon <version>) for anyone consuming the installed package. Confirmed by inspecting the generated file: it carried 0.1.0 before this change and 0.1.2 after.

Fixed by catching the line up to 0.1.2 and adding the annotation, so release-please maintains it from here.

3. Changelog backfill

CHANGELOG.md only records 0.1.0, so without this the history would appear to jump from 0.1.0 straight to 0.1.3. Added entries for the two 2017 releases, taken from their release notes and commits.

One of them is a nice coincidence: the 0.1.1 release of February 2017 was "a serious bug in orbit computing for eldag nodes has been fixed" (commit 92efd09, "Fix orbit formation for eldag nodes"). #13 has just fixed a different bug in the same function.

After this merges

release-please will regenerate the pending release PR against the corrected baseline, and it should then propose 0.1.3 carrying all of #7, #8, #9, #11, #12, #13, #15, #18 and #21. #10 can be closed in favour of that, or will be updated in place.

ctest 3/3, no build changes beyond the version string.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adjusts the project’s release-please metadata and tracked version sources so future automated releases are based on the latest historical release (0.1.2) and the CMake project version is kept in sync.

Changes:

• Update release-please manifest baseline from 0.1.0 to 0.1.2 to prevent re-releasing an already-shipped version.
• Annotate CMakeLists.txt’s project(... VERSION ...) line so release-please maintains the CMake version going forward.
• Backfill CHANGELOG.md entries for the historical 2017 0.1.1 and 0.1.2 releases.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
CMakeLists.txt	Updates project() version to 0.1.2 and adds x-release-please-version annotation for ongoing automation.
CHANGELOG.md	Adds missing historical changelog entries for 0.1.1 and 0.1.2 to preserve release history continuity.
.release-please-manifest.json	Corrects the release baseline to 0.1.2 so the next automated release computes as 0.1.3.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.