[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Marking changes to be backported
From: |
Stefan Monnier |
Subject: |
Re: Marking changes to be backported |
Date: |
Mon, 06 Oct 2014 09:25:49 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
> Yet more branches sounds more complicated to me (doesn't that mean you
> need to know when you make a change where it should go?),
One way or another, someone will have to decide which change goes "in
the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
call it 24.5), or "longer term" (let's call it 25.1).
If the committer knows before committing where that change should go,
then having 3 branches and committing to the proper branch is the
best solution.
If that's not the case, then having 3 branches doesn't help, indeed,
since the commit will have to be backported to the proper branch, if
applicable. Note that this "backporting" will take place regardless of
whether we have 3 branches active at a time or not. Having 3 branches
active at a time, does allow the backporting to be done any time you
want, whereas sticking to the "trunk vs emacs-24" scheme we have simply
means that some of the backporting will only take place once the
"emacs-24" branch is changed from "branch for 24.4" to "branch for
24.5".
Stefan