Re: Merging release branch

[Daniel Martín]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> I know there's other projects that don't do merging at all between
> long-lived branches like this.
>
> In Emacs, that would mean that things that are supposed to be
> emacs-28-only are developed there, and are pushed as normal.  Any things
> that are supposed to go to both master and emacs-28 are committed to
> master, and then cherry-picked for emacs-28.  (Or cherry-picked the
> other way, but that risks "losing" changes if you forget.)

An approach many of those projects follow is that every change is always
developed on master.  Only if a change is considered safe for the
release, it is cherry-picked into the release branch.  Always developing
on master greatly reduces the risk you mentioned about losing changes.

But this workflow is not exent of problems, though, because at the time
you cherry-pick it's possible that the change doesn't apply cleanly to
the emacs-28 branch.  In that case, you'll need to adapt the patch, and
possibly a maintainer would potentially need to review it again to see
if it's still safe enough for the release branch.

The main benefit this approach has is that there is not a single person
doing all the merges periodically, fixing conflicts affecting code he
has not written.  The release branch is never merged back and that means
there's no need to answer the non-intuitive question "should this commit
NOT be merged into master?", for example.  The merging work is
distributed across the people that cherry-pick their commits if they are
deemed safe for the next release.

My two cents.