-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
chore(changelog): new way to maintain the changelog #11279
Conversation
b1d3e6d
to
e7eb0c1
Compare
0ea94c2
to
5b14d8a
Compare
"breaking_change" | ||
] | ||
}, | ||
"scope": { |
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.
If you make this a string we may run into issues like:
plugin
and plugins
Misspelled product names
What if you made this an enum with valid options, and included a misc
keyword for things that dont fit into the options?
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.
Sounds good to me. Updated. Enum value proposal is welcome. Regarding the misc
, we can use null to replace it. changelog entry that set the scope
to null or missing it will be grouped to a default scope.
For example
# 1.yaml
message: add a feature
type: feature
pr: 1
# 2.yaml
message: add b feature
type: feature
scope:
pr: 2
these two changelog entries will be grouped into a default scope.
Would you consider not requiring sequence numbers in file names? If order is important, prefixing with a date ( |
The changelog filename can be anything.(e.g. In the next phase, I will add a CI workflow to automatically extract the changelog message based on the PR title, and use the PR number as the filename, like |
2cc680e
to
558028b
Compare
Co-authored-by: Wangchong Zhou <wangchong@konghq.com>
533d246
to
b9583e2
Compare
Please don't merge this PR. We will merge it on Aug 29th. |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-release/2.8.x release/2.8.x
# Navigate to the new working tree
cd .worktrees/backport-release/2.8.x
# Create a new branch
git switch --create backport-11279-to-release/2.8.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 17c971b51a588d26c0c85dce11784ce516971024
# Push it to GitHub
git push --set-upstream origin backport-11279-to-release/2.8.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-release/2.8.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-release/3.0.x release/3.0.x
# Navigate to the new working tree
cd .worktrees/backport-release/3.0.x
# Create a new branch
git switch --create backport-11279-to-release/3.0.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 17c971b51a588d26c0c85dce11784ce516971024
# Push it to GitHub
git push --set-upstream origin backport-11279-to-release/3.0.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-release/3.0.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-release/3.1.x release/3.1.x
# Navigate to the new working tree
cd .worktrees/backport-release/3.1.x
# Create a new branch
git switch --create backport-11279-to-release/3.1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 17c971b51a588d26c0c85dce11784ce516971024
# Push it to GitHub
git push --set-upstream origin backport-11279-to-release/3.1.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-release/3.1.x Then, create a pull request where the |
Summary Maintaining changelogs in a single markdown file in the repo is one of the easy ways to maintain and also keep consistency. Since Kong has multiple release versions, sometimes a bug fix needs to be backported to all the supported versions after it gets merged to the master branch. The backport bot is currently broken because of the git conflict. We're Introducing a new way to maintain Kong's changelog, which makes the changelog item become an individual file. The idea is, that you don't get the conflict if you don't edit the same file. --------- Co-authored-by: Hans Hübner <hans.huebner@gmail.com> Co-authored-by: Wangchong Zhou <wangchong@konghq.com> (cherry picked from commit 17c971b)
Summary Maintaining changelogs in a single markdown file in the repo is one of the easy ways to maintain and also keep consistency. Since Kong has multiple release versions, sometimes a bug fix needs to be backported to all the supported versions after it gets merged to the master branch. The backport bot is currently broken because of the git conflict. We're Introducing a new way to maintain Kong's changelog, which makes the changelog item become an individual file. The idea is, that you don't get the conflict if you don't edit the same file. --------- Co-authored-by: Hans Hübner <hans.huebner@gmail.com> Co-authored-by: Wangchong Zhou <wangchong@konghq.com> (cherry picked from commit 17c971b)
Summary Maintaining changelogs in a single markdown file in the repo is one of the easy ways to maintain and also keep consistency. Since Kong has multiple release versions, sometimes a bug fix needs to be backported to all the supported versions after it gets merged to the master branch. The backport bot is currently broken because of the git conflict. We're Introducing a new way to maintain Kong's changelog, which makes the changelog item become an individual file. The idea is, that you don't get the conflict if you don't edit the same file. --------- Co-authored-by: Hans Hübner <hans.huebner@gmail.com> Co-authored-by: Wangchong Zhou <wangchong@konghq.com> (cherry picked from commit 17c971b)
Summary Maintaining changelogs in a single markdown file in the repo is one of the easy ways to maintain and also keep consistency. Since Kong has multiple release versions, sometimes a bug fix needs to be backported to all the supported versions after it gets merged to the master branch. The backport bot is currently broken because of the git conflict. We're Introducing a new way to maintain Kong's changelog, which makes the changelog item become an individual file. The idea is, that you don't get the conflict if you don't edit the same file. --------- Co-authored-by: Hans Hübner <hans.huebner@gmail.com> Co-authored-by: Wangchong Zhou <wangchong@konghq.com> (cherry picked from commit 17c971b)
Summary
Maintaining changelogs in a single markdown file in the repo is one of the easy ways to maintain and also keep consistency. Since Kong has multiple release versions, sometimes a bugfix needs to be backported to all the supported versions after it gets merged to the master branch. The backport bot is currently broken because of the git conflict.
I'm Introducing a new way to maintain Kong's changelog, which makes the changelog item become an individual file. The idea is, you don't get the conflict if you don't edit the same file.
Implementation details:
CHANGELOG/changelog
is a Lua script that currently providespreview
, andrelease
commands. It only requires Penlight and lyaml libraries.Notes: