Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] CHANGELOG Fragment Creation Once on Release? #202

Closed
kevinmatthes opened this issue Oct 9, 2023 · 3 comments · Fixed by #279
Closed

[Suggestion] CHANGELOG Fragment Creation Once on Release? #202

kevinmatthes opened this issue Oct 9, 2023 · 3 comments · Fixed by #279

Comments

@kevinmatthes
Copy link
Contributor

Technically, it would suffice to harvest all changes as usual once, on release, such that one big fragment would be generated instead of multiple ones. That fragment would not even be saved in the repository as it would be processed (and, thus, removed) right after its creation during the RONLOG assembly. Aeruginous would therefore harvest all changes from the latest tag on, then.

Would you consider this a useful enhancement, @AmmarAbouZor? If so, I will adjust Aeruginous accordingly and suggest you the corresponding changes to your CI after releasing the respective new version of the tool.

(By the way: the latest version of Aeruginous fixes one of the most annoying bugs RONLOGs had so far -- the random re-ordering during the assembly of a new section; see kevinmatthes/aeruginous-rs#795.)

@AmmarAbouZor
Copy link
Owner

Hi @kevinmatthes Thanks for the suggestion.
This looks promising, it sure would be easier to have less work with the PRs for RONLOG.
You can gladly make the adjustments here and there, I would really appreciate it 😃

@kevinmatthes
Copy link
Contributor Author

I prepared the necessary adjustments in Aeruginous for the suggested feature; see kevinmatthes/aeruginous-rs#797. Please tell me what you think about it and if there might be changes required.

@AmmarAbouZor
Copy link
Owner

I checked the changes in the PR. I think it's great and should work as we wanted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants