On 02/14/2018 06:21 PM, Daan Hoogland wrote:
> the -x would only add it to the comment making it harder to find. As for
> multiple stable branches; merging forward always folows all branches
> forward so a fix on 4.9 would be merged forward to 4.10 and then 4.10 would
> be merged forward again to 4
the -x would only add it to the comment making it harder to find. As for
multiple stable branches; merging forward always folows all branches
forward so a fix on 4.9 would be merged forward to 4.10 and then 4.10 would
be merged forward again to 4.11 and finally to master. of course there is
always
Hi Daan
On 02/14/2018 05:26 PM, Daan Hoogland wrote:
> Rene,
>
> The issue is certainly not due the git workflow but to upgrade schemes we
> have.
>
> The result of this workflow for us is that it is easier to find to which
> branches a particular commit is added as by merging forward the commit
Rene,
The issue is certainly not due the git workflow but to upgrade schemes we
have.
The result of this workflow for us is that it is easier to find to which
branches a particular commit is added as by merging forward the commit id
of the actual fix doesn't change. so instead of looking in each
Hi all
Thanks for taking care of this issue.
However, I wonder how we can prevent such issues in the future and
wondering if this "incident" has its orginos by our current git workflow.
I find the workflow "commit to stable branch --> merge back to master"
is inconvenient. Because at one point,
All,
Given there was no objection to the approach, the concerned PR has been merged
now. I've added a note to the release notes website for 4.10.0.0 users only.
4.11.1.0 will contain the fix, so in case 4.10.0.0 users want to upgrade, they
will not be required to manually run the sql/upgrade-
