You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has become somewhat of an inconvenience to update CHANGES.md before pasting in the release text into the GitHub's own release page, causing a full build before the release build just for that single file.
I don't remember exactly why CHANGES.md was introduced but my assumption is that searching inside it via CTRL+F is simpler than searching within the Releases tab.
Options:
Keep it.
Drop it.
Use a dedicated wiki page instead.
The text was updated successfully, but these errors were encountered:
Yis! Keeping changelog file under version control always feelt wrong, releasing and versioning is much easier when it's decoupled from regular code history, branching and PRs routine.
I only see few non-major benefits of keeping changelog under version control:
Someone can submit a PR fixing small typos/etc, but then they have to be repeated for releases page
If for some reason we'll need to migrate git hosting to lets say GitLab, migrating releases page will be a manual work
Releases could potentially be lost in case of GitHub failure
Offline access
All of them except №1 could be somewhat solved by duplicating changelog in version tag message.
So I'd propose to only leave a link in the changelog file that'll point to Releases page and maintain changelog on releases page (and optionally in git tag messages).
It has become somewhat of an inconvenience to update
CHANGES.md
before pasting in the release text into the GitHub's own release page, causing a full build before the release build just for that single file.I don't remember exactly why
CHANGES.md
was introduced but my assumption is that searching inside it via CTRL+F is simpler than searching within the Releases tab.Options:
The text was updated successfully, but these errors were encountered: