Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upMore precise Changelog #976
Comments
|
Sure, I have started to update changelog retroactively for 8.0 release, but I understand it may seem not enough for certain changes. It may help to set a policy not to integrate a change that does not contain a changelog mention. Certainly, all PRs updating changelog to be more verbose is welcome. I just would like to refrain from copying the commit history to the changelog - maybe more verbose commit messages would be in order? Keeping commits small is an advantage when resolving conflicts. Current integration policy (although not set in stone, or anywhere for that matter) now is to squash all commits of a PR when most of them are just cosmetic (lint fixes etc), and to make a merge commit when a PR is wider and commits make sense one at a time. Then, the merge commit summarizes the intent of the PR. Makes sense? |
|
I agree, if the tag refactoring PR was squash merged, and the problem with nested table layout was caused by it, I would have really struggled to find what went wrong. Using the merge strategy for huge refactoring is definitely a good thing. |
|
@machour Would you like to recommend a change to https://github.com/mpdf/mpdf/blob/development/.github/CONTRIBUTING.md to publish this new policy? |
|
@fulldecent Do you mean "To be incorporated, the PR must contain a change in the CHANGELOG.md file describing itself" that is the last bullet point in the CONTRIBUTING.md file? |
|
Yes, that looks good in there. It seems like this issue is addressed "a more precise Changelog starting with v8". Perhaps this issue can be closed. |
|
I don't think this issue can be closed just because there's a mention in the documentation that the Changelog can be updated. Example: I don't see any mention to 35e592c in it |
|
Let's leave it open a bit longer mostly to remind me of the new rule. |
Hi @finwe
Would it be possible to have a more precise Changelog starting with v8, listing all changes happening between every minor releases?
Current handling make it really hard to understand what happened precisely when. The commit log isn't really helping as the merge strategy used on this repo is merge, rather than squash, resulting in a multitude of small commits, sometimes containing "cryptic" messages logs.
If the issue is just a matter of time, I'll be glad to maintain that file.
Additionally, the relevant portion of the Changelog would be copied to the GitHub release message, making it even easier to see what changed from the releases tab.
Let me know how we can enhance this.