41–50 of 53 posts
Earlier quoted context omitted.
It always depends on your users. Such a changelog is suitable for stuff other developers use, but not for end users. But it is a _way_ better starting point to write a changelog that 'usual' commit messages or PR descriptions.
How can I, as a user, know if bug x, or issue y is resolved, without a changelog?!
Re “ Regional date formats vary throughout the world and it's often difficult to find a human-friendly date format that feels intuitive to everyone. The advantage of dates formatted like 2017-07-17 is that they follow the order of largest to smallest units: year, month, and day.” I disagree. ISO 8601 is great for machine readable dates. For human readable dates I prefer to spell the month out. 17 July 2017 is more re…
For a changelog in text format I think it is safe to assume the reader will understand yyyy-mm-dd, and it is safer than dd/mm/yyyy or mm/dd/yyyy due to the lack of ambiguity. Also if they don't understand they'll know and hopefully learn the standard, where with other numeric formats they could blindly assume they have understood.
> 17 July 2017 is more readable than 2020-07-17
I don't agree there, but that could be what I'm used to. The textual month at least removes the ambiguity so is significantly preferable to the same order in a numeric-only form.
> Yes it is in English but if your audience is in English…
But if a chunk of your audience is American? IIRC they generally verbalise dates in mdy order which is why they ended up using that order in numeric forms, so they may find it as jarring, or more so, as ymd. Not that I alter my spelling for American comfort, but as clarity-to-the-audience is the arguement here…
If course if the text you are working on is mainly for your benefit, forget everyone else and do what works best for your style/comprehension/preference.
Re “ Regional date formats vary throughout the world and it's often difficult to find a human-friendly date format that feels intuitive to everyone. The advantage of dates formatted like 2017-07-17 is that they follow the order of largest to smallest units: year, month, and day.” I disagree. ISO 8601 is great for machine readable dates. For human readable dates I prefer to spell the month out. 17 July 2017 is more re…
YYYY-MM-DD is completely unambiguous.
Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…
> Ugh. One of my pet peeves is the generation of release notes from commit messages. Commit messages and PR descriptions have a different audience (i.e. contributors) from release notes (i.e. users).
> For example, take a look at ESLint's autogenerated changelog [1]:
67c0074 Update: Suggest missing rule in flat config (fixes #14027) (#15074) (Nicholas C. Zakas)
cf34e5c Update: space-before-blocks ignore after switch colons (fixes #15082) (#15093) (Milos Djermanovic)
c9efb5f Fix: preserve formatting when rules are removed from disable directives (#15081) (Milos Djermanovic)
14a4739 Update: no-new-func rule catching eval case of MemberExpression (#14860) (Mojtaba Samimi)
7f2346b Docs: Update release blog post template (#15094) (Nicholas C. Zakas)
fabdf8a Chore: Remove target.all from Makefile.js (#15088) (Hirotaka Tagawa / wafuwafu13)
e3cd141 Sponsors: Sync README with website (ESLint Jenkins)
05d7140 Chore: document target global in Makefile.js (#15084) (Hirotaka Tagawa / wafuwafu13)
0a1a850 Update: include ruleId in error logs (fixes #15037) (#15053) (Ari Perkkiö)
47be800 Chore: test Property > .key with { a = 1 } pattern (fixes #14799) (#15072) (Milos Djermanovic)
a744dfa Docs: Update CLA info (#15058) (Brian Warner)
9fb0f70 Chore: fix bug report template (#15061) (Milos Djermanovic)
f87e199 Chore: Cleanup issue templates (#15039) (Nicholas C. Zakas)
> What's worked very well for me is to simply have an "I updated the changelog, if applicable" entry in my PR template checklist. Then when I cut a new release, I simply add the release date above the release notes currently listed under "Unreleased", and they'll list all relevant changes, reviewed during the pull request to verify that it is relevant to users.
> [1] https://github.com/eslint/eslint/blob/master/CHANGELOG.md
Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…
I'm having trouble figuring out what a "semantic pull request" is from that link, it's not a concept I've heard of before, and I'm interested. I mean, i assume it's some conventions for what goes in PR message, but what are they? Is there a better link? In general, as a developer-consumer of them, I have found automatically-generated-from-commits changelogs to be not so useful, but I don't know if I've experienced an…
It forces you to think a moment for a good PR title, but it is an small price to pay when it gives you a 0 extra work changelog that is good enough for semi-internal use.
Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…
I also recognize that for full-speed delivery, they are suboptimal in that they sit directly on the critical path. After reviewing the code of the PR, there is now an extra context switch to also review the title/semantics.
So the complexity of turning a list of PRs into a changelog does not disapper, it gets hidden within each individual PR.
Earlier quoted context omitted.
I'm having trouble figuring out what a "semantic pull request" is from that link, it's not a concept I've heard of before, and I'm interested. I mean, i assume it's some conventions for what goes in PR message, but what are they? Is there a better link? In general, as a developer-consumer of them, I have found automatically-generated-from-commits changelogs to be not so useful, but I don't know if I've experienced an…
You use the title of the PR as a changelog item instead of every commit message. It forces you to think a moment for a good PR title, but it is an small price to pay when it gives you a 0 extra work changelog that is good enough for semi-internal use.
git --no-pager log | grep 'CHANGELOG: '