Task #5661
closed
Revise branching, tagging, and release guide info
I suggest to add information either to wiki or to the docs about cherry picking the changelog and version changes commits.
E.g. if after branching date, there are some bugfixes to cherry-pick and there are already new features in the master. Where changelog is generated (for the release branch?) and should PR be open against release branch first and cherry-picked into the master? Or should we submit PR with changelog against master anyway?
I would imagine that we'd submit PR with the changelog against master and then it would be cherrypicked into the release branch.
I was imagining you generate the changelog on the branch and then cherry pick to master. If you do the reverse then the z-stream will receive changelog entries that are unmerged to the z-stream branch. This is what I did for pulpcore and pulp_file for example. Also I generate the changelog in one commit using `towncrier --version` and the version bumps in another commit. This lets me cherrypick only the changelog to master without the versions on master changing and then needing an additional update.
Why does this need to be in the docs as opposed to the wiki? I'm not opposed, per se, but I'm not sure how much value the community would get from this being in our contribution docs. The actual release process will be handled by the core team members (or possibly automated away entirely as we've discussed lately).
- Sprint changed from Sprint 62 to Sprint 63
- Status changed from NEW to ASSIGNED
- Assignee set to bmbouter
- Sprint/Milestone deleted (
3.0.0)
- Subject changed from Add branching, tagging, and release guide info to documentation to Revise branching, tagging, and release guide info
- Description updated (diff)
- Status changed from ASSIGNED to CLOSED - COMPLETE
Rewrote to reflect the IRC decision to keep these docs on the wiki for now.
Also available in: Atom
PDF