On Fri, 30 Mar 2012 02:59:29 +0200, Yasuo Ohgaki <yohg...@ohgaki.net>
wrote:
Since the git work flow in the wiki requires to apply patch to
lowest possible branch, then merge upwards.
This changes old work flow, commit trunk, then merge to
release.
I've committed simple build problem fix to all branches, I think
release masters don't care such merge. However, how about
feature changes?
I have simple patch for
Request #47570 libpq's PG_VERSION should be exported to userland
https://bugs.php.net/bug.php?id=47570
This is simple change, but it's new feature. (I added 2 new module
constants for PG_VERSION, PG_VERSION_STR)
Question is "What's the standard work flow for new features?"
I don't see how this is any different. "Lowest possible branch" doesn't
necessarily mean 5.3. It can mean 5.4 or master.
If the feature is not appropriate for 5.3, but it is for 5.4 and master,
commit it to 5.4 and merge 5.4 into master. Or it can be appropriate just
for master, in which case there's no merge into other branches. This is
the most common scenario -- when a commit is applicable to one branch and
all other more recent ones.
The problem with the current workflow is only when you have something
specific to a lower branch, which is not applicable to upper branches
because the code base has diverged. You still have to merge upwards in
those situations and resolve the likely conflict (typically with the
"ours" strategy).
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
