We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
The release process of this gem is not well described.
If #91 works as expected, I suggest adding a RELEASE_PROCESS.md file as below
RELEASE_PROCESS.md
When creating a PR to master you should include a text fragment like this in the PR description
master
# Changelog ## Unreleased * [ADDED|CHANGED] One line description of a change * [ADDED|CHANGED] Second description of another change
On merging to master, you should set one of the following labels:
release-patch
release-minor
release-major
This document explains how the release.yml workflow updates the CHANGELOG.md file during a release.
release.yml
CHANGELOG.md
The following section of release.yml handles extracting the latest release notes from a pull request and updating CHANGELOG.md accordingly.
echo "${{ github.event.pull_request.body }}" | csplit -s - "/##/" echo "# Changelog ## ${{ env.VERSION }} " >> CHANGELOG.tmp grep "^*" xx01 >> CHANGELOG.tmp grep -v "^# " CHANGELOG.md >> CHANGELOG.tmp cp CHANGELOG.tmp CHANGELOG.md
echo "${{ github.event.pull_request.body }}" | csplit -s - "/##/"
##
xx00
xx01
echo "# Changelog
" >> CHANGELOG.tmp
Appends a new changelog section for the upcoming release.
${{ env.VERSION }} contains the version number (e.g., 4.1.0).
${{ env.VERSION }}
4.1.0
Results in an initial structure like:
grep "^*" xx01 >> CHANGELOG.tmp
*
grep -v "^# " CHANGELOG.md >> CHANGELOG.tmp
# Changelog
## X.Y.Z
CHANGELOG.tmp
cp CHANGELOG.tmp CHANGELOG.md
This ensures that the latest release notes appear at the top, and all previous release notes remain intact without duplicate headers.
This automated approach prevents manual errors in updating the changelog and streamlines the release process for maintainers.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
The release process of this gem is not well described.
If #91 works as expected, I suggest adding a
RELEASE_PROCESS.md
file as belowCutting a new release
When creating a PR to
master
you should include a text fragment like this in the PR descriptionOn merging to
master
, you should set one of the following labels:release-patch
- to release a new patch version (eg: 5.0.1 or 6.1.1)release-minor
- to release a new minor version (eg: 5.1 or 5.2 or 6.1)release-major
- to release a new major version (eg: 5.0 or 6.0)Underlying Code
Understanding the Release Process in release.yml
This document explains how the
release.yml
workflow updates theCHANGELOG.md
file during a release.Breakdown of the Key Code Block
The following section of
release.yml
handles extracting the latest release notes from a pull request and updatingCHANGELOG.md
accordingly.Extract the Changelog Entry from the PR Body
echo "${{ github.event.pull_request.body }}" | csplit -s - "/##/"
##
(indicating a version header in Markdown).xx00
,xx01
, etc.xx01
contains the new changelog entry from the PR.Create a New Changelog File
echo "# Changelog
${{ env.VERSION }}
" >> CHANGELOG.tmp
Appends a new changelog section for the upcoming release.
${{ env.VERSION }}
contains the version number (e.g.,4.1.0
).Results in an initial structure like:
Changelog
4.1.0
Extract the Changelog Content
grep "^*" xx01 >> CHANGELOG.tmp
xx01
that start with*
(bullet points for changes).Append the Existing Changelog (Without H1 Headers)
grep -v "^# " CHANGELOG.md >> CHANGELOG.tmp
# Changelog
H1 header fromCHANGELOG.md
.## X.Y.Z
version headers and their contents.# Changelog
title exists.CHANGELOG.tmp
.Overwrite
CHANGELOG.md
with the Updated Versioncp CHANGELOG.tmp CHANGELOG.md
CHANGELOG.md
withCHANGELOG.tmp
.Summary
CHANGELOG.tmp
with the new version number.# Changelog
) header fromCHANGELOG.md
and appends the rest.CHANGELOG.md
with the updated version.This ensures that the latest release notes appear at the top, and all previous release notes remain intact without duplicate headers.
This automated approach prevents manual errors in updating the changelog and streamlines the release process for maintainers.
The text was updated successfully, but these errors were encountered: