axodotdev / axodotdev/cargo-dist
multiple `CHANGELOG.md` files
- Dominant language
- Rust
- Stars
- 2.1k
- Forks
- 149
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 32
Description
π awesome work so far!
I'd like to request a feature that would allow me to automatically fill in GitHub Release notes when releasing a new version of a package in the context of a virtual workspace, with independent versions (tagging each package like "my-app-v1.0.0").
My dir structure project looks like this:
```
.
βββ Cargo.toml
βββ CHANGELOG.md
βββ README.md
βββ project_A
β βββ Cargo.toml
| βββ CHANGELOG.md
| βββ README.md
β βββ src
βββ project_B
βββ Cargo.toml
βββ CHANGELOG.md
βββ README.md
βββ src
```
Both `project_A` and `project_B` are registered as members in `/Cargo.toml`, and issuing `cargo release -p project_A 0.1.1` works as expected, however, what I'd love to see is that `cargo-dist` would go and read `project_A/CHANGELOG.md` and find `# 0.1.1` and use the content below the found heading to fill the release notes in GitHub Releases for the `project_A-v0.1.1` release.
For my project, my preference is to keep separate `CHANGELOG.md` files per package (they are independent of each other, but they are consumed by the same thing, tldr each package is a plugin/extension).
Let me know if I can help! I suppose the `self.inner.announcement_changelog` would need to receive the content of `project_A/CHANGELOG.md` instead of `/CHANGELOG.md` in `fn compute_announcement_changelog`?
The path is being passed from here https://github.com/axodotdev/cargo-dist/blob/b0f820c655b3a2ba6b019fdf850a40fba08619dc/cargo-dist/src/tasks.rs#L1422-L1425
Contributor guide
Research direction
Read cargo-dist/src/tasks.rs at the referenced lines and trace compute_announcement_changelog, including self.inner.announcement_changelog. Use the project_A/CHANGELOG.md layout and package-specific version heading as the reference case; done means the project_A GitHub release uses the content below that heading rather than the workspace changelog.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, rust
- Domain
- release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100