Thanks Graham, very helpful.
Question left is when/where is patches/2.4.x and patches/trunk used ?
Free to use ? You do not mention them in the process.
Resume:
CTR: trunk
RTC: branches/2.4.x
RTC: 2.5.0-alpha
? : patches/2.4.x
? : patches/trunk
The RTC is not always followed. I see mostly that for example config,
cmake and .dsp changes are not RTC, they are just applied to all
the repo's
Regards,
Steffen
On Saturday 04/11/2017 at 11:59, Graham Leggett wrote:
On 04 Nov 2017, at 12:03 PM, Steffen <i...@apachelounge.com> wrote:
Soon we have:
branches 2.4.x
trunk
2.5.0-alpha
patches/2.4.x
patches/trunk
Please a procedure: where and when do we apply patches/fixes.
When: When you feel your change is appropriate, and when on
review-then-commit branches you have received three +1’s including
yours binding vote.
Where: Read on.
Everything starts on bleeding edge trunk, always, just as we always
have done.
People propose backports to the older branches, in order, if people
feel those patches are warranted, just as we always have done.
If a branch is commit-then-review (CTR), and you believe it is
appropriate to do so, you commit to that branch, and if people have a
problem with it, they will say so.
If a branch is review-then-commit (RTC), and you believe it is
appropriate to do so, you propose a backport in STATUS and when you
get three +1’s (including your own binding one), you commit to that
branch.
The changes cascade down the branches as far as you feel is
appropriate.
Concrete example.
You have a change. You believe this change should be backported to
v2.4.x, so that people using the current v2.4.x line will see your
change. You commit it to trunk. You propose it for backport to
v2.5.0-alpha. You propose it for backport to v2.4.x. You could carry
on down to v2.2.x if you believe it is warranted, but you probably
won’t believe it is warranted for a branch that is end of life.
What do we want?
- All changes on v2.2.x should also appear in all higher branches and
trunk.
- All changes on v2.4.x should also appear in all higher branches and
trunk.
- All changes on v2.5.x should also appear in trunk.
What _don’t_ we want?
- Changes to appear on v2.4.x that _aren’t_ also made to v2.5.x. For
obvious reasons we don’t want things in v2.4.x to suddenly vanish
from v2.5/v2.6; except for
- Code that only appears in older branches. For example if a module is
removed, you physically can’t patch it in trunk because it no longer
exists. In these rare cases you would propose a fix for an older
branch only. The rule here is “be sensible”.
Nothing has changed in our process.
Regards,
Graham
—
