Hi RMs,
we currently use release branches which we don't merge back into the
original branch.I would like to propose to change this and merge the
release branch back into it's parent branch. To the est of my
remembrance not doing this is a reminder of SVN merge tracking annoyance
which is not relevant anymore.
The reason for this change is that it makes it hard to find out whether
a patch was part of a release or not and which release it appeared in
first.
The suggested work flow (pushes ignored) is like this:
1. git checkout PHP-X.Y
2. git branch PHP-X.Y.Z
3. vim NEWS configure.in main/php_version.h && git commit (set to
next version X.Y.Z+1)
4. git checkout PHP-X.Y.Z
5. test, cherry pick and release RCs as needed
6. vim NEWS configure.in main/php_version.h && git commit (for
release)
7. git tag -s php-X.Y.Z
8. git checkout PHP X.Y
9. git merge PHP-X.Y.Z
10. resolve merge conflict in NEWS and other files && git commit
The only change to the current procedure should be that instead of 9 and
10 one currently manually merges NEWS files.
johannes
Hi RMs,
we currently use release branches which we don't merge back into the
original branch.I would like to propose to change this and merge the
release branch back into it's parent branch. To the est of my
remembrance not doing this is a reminder of SVN merge tracking annoyance
which is not relevant anymore.The reason for this change is that it makes it hard to find out whether
a patch was part of a release or not and which release it appeared in
first.The suggested work flow (pushes ignored) is like this:
1. git checkout PHP-X.Y 2. git branch PHP-X.Y.Z 3. vim NEWS configure.in main/php_version.h && git commit (set to next version X.Y.Z+1) 4. git checkout PHP-X.Y.Z 5. test, cherry pick and release RCs as needed 6. vim NEWS configure.in main/php_version.h && git commit (for release) 7. git tag -s php-X.Y.Z 8. git checkout PHP X.Y 9. git merge PHP-X.Y.Z 10. resolve merge conflict in NEWS and other files && git commit
This was missing a step already done with current procedure:
11. Merge up till reaching master
as we do for all other commits, obviously.
johannes
On Wed, Apr 2, 2014 at 2:35 PM, Johannes Schlüter johannes@schlueters.dewrote:
Hi RMs,
we currently use release branches which we don't merge back into the
original branch.I would like to propose to change this and merge the
release branch back into it's parent branch. To the est of my
remembrance not doing this is a reminder of SVN merge tracking annoyance
which is not relevant anymore.The reason for this change is that it makes it hard to find out whether
a patch was part of a release or not and which release it appeared in
first.The suggested work flow (pushes ignored) is like this:
1. git checkout PHP-X.Y 2. git branch PHP-X.Y.Z 3. vim NEWS configure.in main/php_version.h && git commit (set to next version X.Y.Z+1) 4. git checkout PHP-X.Y.Z 5. test, cherry pick and release RCs as needed 6. vim NEWS configure.in main/php_version.h && git commit (for release) 7. git tag -s php-X.Y.Z 8. git checkout PHP X.Y 9. git merge PHP-X.Y.Z 10. resolve merge conflict in NEWS and other files && git commitThis was missing a step already done with current procedure:
11. Merge up till reaching masteras we do for all other commits, obviously.
johannes
Hello,
I'm not against this, but I don't feel the point.
Branching back to the original branch will just create one more commit,
adding some merging conflicts (NEWS).
What if we have cherry piked commits about CVE, will they conflict as well ?
I'm not feeling very well yet with git, so that's why I ask.
Julien
Hi!
I'm not against this, but I don't feel the point.
Same here, I have no problem doing it, just not sure what that would
give us. I.e. I'm not sure I'm getting the part about how it makes
easier to find out if the patch is part of the release or not. Johannes,
could you explain a bit more on that?
Thanks,
Stas