jose-compu / jose-compu/logosdb
Release hygiene: sync CHANGELOG and version metadata for 1.0.1
- Dominant language
- C++
- Stars
- 13
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Post-`1.0.0` release hygiene: `CHANGELOG` still marks several shipped `0.x` releases as *(unreleased)*, `LOGOSDB_VERSION_*` in the public header lags at `0.9.0`, MCP self-reports `0.11.0`, and docs (`README` roadmap, `SECURITY.md` supported versions, `RELEASING.md` examples) still read as pre-1.0.
## Scope
- [ ] Date and close out `CHANGELOG` entries for shipped `0.9.1`–`0.12.0` and add a proper `1.0.0` section
- [ ] Add `1.0.1` patch entry for this hygiene release
- [ ] Align version metadata: `logosdb.h`, `CMakeLists.txt`, `pyproject.toml`, `nodejs`/`mcp`/`n8n` `package.json`, MCP server self-reported version, workspace lockfile / `logosdb` dependency ranges
- [ ] Update `.md` docs for post-1.0 semver / supported versions / release examples
## Acceptance
- [ ] All package and library version strings report `1.0.1`
- [ ] `CHANGELOG` has no stale *(unreleased)* markers for versions already shipped
- [ ] README / SECURITY / RELEASING reflect stable `1.x` support
## Out of scope
- Feature work, Windows port (#10), remaining Python adapter audit (#111)
Contributor guide
Research direction
Start by inventorying version strings in CHANGELOG, logosdb.h, CMakeLists.txt, pyproject.toml, the nodejs/mcp/n8n package.json files, the MCP server, and the workspace lockfile. Then review README, SECURITY.md, and RELEASING.md for pre-1.0 wording. Done means all package and library versions report 1.0.1, shipped releases are dated and closed, and the docs reflect stable 1.x support.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, cpp, markdown, nodejs, python
- Domain
- build-system, documentation, release
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100