Re: Next release from master

[Barry Fishman <barry@ecubist.org>]

On 2016-01-21 23:38:58 -0800, John Wiegley wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> What do you think, Eli? Should master become 26.1?
>> If we decide that emacs-25 will only be used for fixing bugs, i.e. all 25.x
>> releases after 25.1 will be bugfix releases, then yes, I think master should
>> become 26.1.
>
> I actually sort of like this plan. Even when 25.1 is out, I'd love to spend
> some time getting the bug list under control before we move on to brave new
> features, if others are up for it.

I think you all are making things more difficult for yourselves.

I think master should be the focus of release testings.  When bugs are
fixed in a release this would be done in master.  When things are ready
for release they are fast-forwarded in to the numbered release branch,
and tagged.  So the each release branch just has the complete,
development of that release.

Major changes would start with master and be branched into their own
initial development branch.  Ultimately they could be integrated into the
"next" branch.  This is where new ideas that you don't want to add to
the current release would be integrated.  Important bug fixes could be
merged in here, but this is not crucial.  The idea of the "next" branch
is to get new ideas all working together.

When you are ready for a new release, the "next" branch is merged into
"master".  This is important because it is the responsibility of the
people coding in fundamental changes to get them working in the baseline
emacs and not the other way around.  When you merging the last release into
the next, its the already tested bug fixes that flag changes, which
seems backwards.

One might even consider branching "master" into a temporary branch, then
merging in "next".  (Of even branching "next" as the new temporary
branch and rebasing with "master").  This way the initial merge fixes
can be performed prior to fast forwarding into "master" for general
testing, and master does not go though a period of major breakage.

After this major version update of master, security fixes would be added
to released branches without going through master.

In this way master is the testing branch, and people can rely on just
getting master if they want to help test Emacs.  The "next" branch is
were the latest features are added, possibly after they are tried and
evaluated in their own branches.

The important thing is that you want in mergers to focus on fixing new
features not old tested bug fixes.

--
Barry Fishman