-
Notifications
You must be signed in to change notification settings - Fork 133
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
Backfill 1.2.2 to changelog #4472
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, I think this is a good idea in principle.
But I would suggest to link to the PRs that implemented a fix. That way one can easily find out more information about a given fix.
Co-authored-by: Max Horn <[email protected]>
BTW, not a complaint, but, why isn't this in PR #4448? Don't they basically do the same thing, i.e. add CHANGELOG.md, just with different content? |
|
||
### Fixed | ||
|
||
- Fixed a problem with `galois_group` [PR #4396](https://github.com/oscar-system/Oscar.jl/pull/4396) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's better. I've now adjusted #4396 to use this as title, and added the "use title" label.
We also should add labels reflecting the categories we use. While I am still not convinced that "Added" / "Changed" / etc. are what we want (after all the description usually makes that clear already: "Fixed a problem with ..."), I am OK with trying that out for now, we can then iterate.
But that would suggestion suitable labels. E.g. category: change
, category: fix
, category: addition
(or any different prefix, like kind:
or type:
. Or no prefix, whatever. As long as there is a way to find out which labels are relevant. Having a common prefix simply makes that easier)
Closed in favor of #4448 |
This depends on #4448 , just a first draft of what a backfilled changelog for v1.2.2 could look like.
This skips the following compared to the autogenerated changelog in the release page :