Project

Profile

Help

Task #5661

Add branching, tagging, and release guide info to documentation

Added by bmbouter about 1 month ago. Updated 2 days ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Documentation
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 63

Description

Currently the branching and cherry picking process is described in this blog post: https://github.com/pulp/pulpproject.org/pull/223

Also the release guide for pulpcore is kept on the wiki here: https://pulp.plan.io/projects/pulp/wiki/Pulp3_Release_Guide

Both of these need to be migrated into pulpcore's documentation.

History

#1 Updated by daviddavis 20 days ago

  • Sprint set to Sprint 62

#2 Updated by ttereshc 20 days ago

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?

#3 Updated by ipanova@redhat.com 19 days ago

I would imagine that we'd submit PR with the changelog against master and then it would be cherrypicked into the release branch.

#4 Updated by bmbouter 19 days ago

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.

#5 Updated by dalley 7 days ago

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).

#6 Updated by rchan 2 days ago

  • Sprint changed from Sprint 62 to Sprint 63

Please register to edit this issue

Also available in: Atom PDF