It appears that we have several possible scenarios available to us, and each
has its trade-offs.

OPTION #1 (closest to the status quo)

  25.1 is developed on emacs-25
  25.2 is concurrently developed on master
  26.1 is concurrently developed in other branches
  
  LABOR: We need to move 26.1 commits out of master and into some other
  branch. Bugs that were marked "fixed in 25.2" that shouldn't have been, need
  to be updated to say "fixed in 26.1".

OPTION #2

  25.1 is developed on emacs-25
  25.2 is concurrently developed on emacs-25-next
  26.1 is concurrently developed on master

  LABOR: Again, splitting the commits between master and emacs-25-next.  Same
  work as option #1.

  DOWNSIDE: 'master' potentially becomes much more unstable, and yet this is
  the default branch when people pull from Git.  Solution: Change the default
  branch to emacs-XX-next.

OPTION #3

  25.1 is developed on emacs-25
  26.1 is concurrently developed on master

  This means dropping point releases, except for back-patching severe bug
  fixes onto emacs-25.

  DOWNSIDE: Package authors will experience API breakages more often, since
  every release of Emacs is now free to break them. There would be no policy
  of compatibility, as there is now (mostly) between point releases.

  Unless you've managed a large Emacs project used by many, I'm not sure you
  fully understand what is implied by this decision. Someone suggested just
  cutting a new release arbitrarily every X months, but I don't feel that is a
  realistic option.

OPTION #4

  ???

Since the core developers are the ones doing the work, what works for them is
what we should do. If everyone wants API-breaky releases more often, we should
consider that option. However, my preference is option #1, as it is the one
that most emphasizes stability over "new features".

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2