openwisp / openwisp/openwisp-utils
[feature/fix] Excluding backported fixes from feature release change logs
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 93
- Forks
- 104
- Avg merge
- 14h 10m
- Merged PRs (30d)
- 22
Description
Follow up of #496.
We should do this once #496 is completed.
Two ways that we can both use to avoid duplicating backported bugfixes in the change log of new feature releases.
Step 1: automatically determine from current stable branch.
- Detect whether we are on the main branch (master/main), if we are not, stop, else continue
- Now we need to find out what's the latest stable version branch, I think a reliable way to do this would be to look at tags/releases (whatever is easier, if we use tags, we'll need to run
git pull --tagsfirst), look for the latest feature release, eg: 1.1.0, so we know the current stable branch is1.1 - If the branch does not exist, stop, else continue
- Get the git log for the stable branch from the latest stable release onwards
- Most commits contain the original commit hash from which they were cherry picked from in the main branch, eg: https://github.com/openwisp/openwisp-utils/commit/6eadd4e6594ac8e2ba437b1a0e178c69b12540c4, see
(cherry picked from commit 5a32721), if this line is missing, stop, else continue - Fetch all the "cherry picked from commit" hashes and compile a temporary ignore file for gitcliff, or an alternative equivalent solution, as long as it works and is efficient
Step 2: [backport] tag mentioned (related to #501)
- Loop over all the commits that are going to be included in the change log, if the commit message contains
[backport], skip them or add them to the gitcliff ignore file (whatever makes the code easier to maintain/read).
Using both methods is redundant by design to catch most cases, including when we may forget to use the [backport] tag and perform the backport manually with git cherry-pick -x.
Step 3: cleanup
The ignore file for git-cliff should be generated on the fly, used during release process, and then discarded.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing follow-up issue #496 and the release process that invokes git-cliff. Trace how branches, tags, commit logs, cherry-picked commit markers, and [backport] messages are currently handled. Done means backported fixes are excluded from feature-release changelogs using a temporary ignore file that is generated during release and discarded afterward.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git
- Domain
- release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100