Hi,
So 2.5.0-alpha will be RTC.
Good for me, it is what I personally prefer.
Will it be a fork of latest 2.4.x and trunk things will have to be
proposed, voted and backported?
Or will it be a fork from trunk with things likely never (IMHO) really
reviewed?
My own opinion is a copy of 2.4.x + RTC process because I think it is
safer. But I'm not sure it is what others have in mind.
CJ
Le 04/11/2017 à 11:59, Graham Leggett a écrit :
On 04 Nov 2017, at 12:03 PM, Steffen <[email protected]
<mailto:[email protected]>> 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
—
