Update branching guide to a post-PUP3 world #3336
Conversation
| @@ -78,7 +74,7 @@ Hotfix | |||
| When a hotfix needs to be made, a branch will be created from the most recent | |||
| ``x.y.z`` release tag. The fix will be made (via pull request from a personal | |||
| fork to the hotfix branch), a new tag will be built from the tip of the hotfix | |||
| branch, and the hotfix branch can be merged to ``x.y-dev``. | |||
| branch, and the fix can be cherry-picked forward to ``x.y-release`` and ``master``. | |||
There was a problem hiding this comment.
I was thinking that hotfixes could just be made against the x.y-release branch and then cherry picked back to master.
pcreech
force-pushed
the
branching-guide-update
branch
from
16d277a
to
ad43260
Compare
pcreech
force-pushed
the
branching-guide-update
branch
3 times, most recently
from
e2c0001
to
bf16457
Compare
| features as encouraged by `Semantic Versioning <http://semver.org/>`_. | ||
| bugfix development on the ``master`` branch with cherry-picking fixes into | ||
| +``x.y`` streams as necessary. This version scheme is based | ||
| +on the `Semantic Versioning <http://semver.org/>`_ strategy. |
There was a problem hiding this comment.
++ is a copy-paste artifact, the second + is a part of the actual document
There was a problem hiding this comment.
Yeah, ctl-s failure. I guess we had a race condition in you reviewing and me pushing, but that's fixed now
| Each ``x.y`` release will have one corresponding branch called ``x.y-dev``. For | ||
| example, all work for the 2.7.z series of releases gets merged into ``2.7-dev``. | ||
| Each ``x.y`` release will have one corresponding branch called ``x.y-release``. Fixes | ||
| are cherry-picked back to these branches for each x.y.z release. |
There was a problem hiding this comment.
x.y.z should be enclosed by double-backticks
| @@ -61,12 +58,10 @@ Builds will be represented only as tags. | |||
| Build Lifecycle | |||
There was a problem hiding this comment.
This isn't part of your changes, so Github won't let me comment directly on it.
Above this, in the "Build Tags" section, x.y needs to be enclosed by double-backticks
| fork to the hotfix branch), a new tag will be built from the tip of the hotfix | ||
| branch, and the hotfix branch can be merged to ``x.y-dev``. | ||
| When a hotfix needs to be made. The fix will be made (via pull request from a personal | ||
| fork to the ``x.y-release`` branch), a new tag will be built from the tip of the |
There was a problem hiding this comment.
We should specify that it should be cherrypicked to master but still merged via a separate PR.
Random sidenote: we need to make a better distinction in our other docs about the difference between a hotfix and a bugfix. I don't really understand the reasons for the difference in procedure between the two.
pcreech
force-pushed
the
branching-guide-update
branch
from
bf16457
to
f472735
Compare
With the acceptance of PUP3, branching and merging has significantly changed. This is to update the docs to reflect the new state of the development work flow. closes pulp#3246 https://pulp.plan.io/issues/3246
pcreech
force-pushed
the
branching-guide-update
branch
from
f472735
to
8db4372
Compare
With the acceptance of PUP3, branching and merging has significantly
changed. This is to update the docs to reflect the new state of the
development work flow.
closes #3246
https://pulp.plan.io/issues/3246