Re: Next release from master

["Alex Bennée" <alex.bennee@linaro.org>]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Barry Fishman <barry@ecubist.org> writes:
>
>> I suggested branches not have modes. "Master" would always be where the
>> major testing occurs. "Next" would be were new, possibly destabilizing
>> changes could be made. Numbered branches would always contain the history
>> associated with that release.
>
> Ah, I _think_ this is just what I was suggesting with "emacs-25", "master" and
> "next" before, but it was felt that 3 branches is not yet better than two. So
> I think we'll stick with two until we feel a more pressing need.

It really depends on what you want happening in the various branches. To
give another example from QEMU our strategy is:

* master is always the latest greatest
* as we approach release the criteria to commit to master gets tighter
  - soft feature freeze, no new features (only features that are "ready" get merged, maybe in stages)
  - hard feature freeze, any feature for this cycle needs to be in my then
  - release candidates, bug fixes only
  - release x.0

Once the x.0 release is done a stable branch is created for future .n
releases and the metaphorical flood gates opened for features that
weren't ready for the last cycle can go in.

Of course the control of this is helped by  the fact we have a lead
maintainer who merges pull requests from the subsystem maintainers
(much like the Linux kernel). Very few people have direct commit rights
to the master repository.

Would you have people with code that needs to go somewhere during a
stabilisation cycle? I would hope anything funky just lives on feature
branches until the next dev cycle opens.

--
Alex Bennée