Re: Next release from master

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think this is all kinda confusing. In the past, we've had one release
> branch (currently emacs-25) and one branch for development (of "normal",
> uncontroversial features). I think that worked very well. If we're now to be
> in a tripartite world of ... world, that's both unusual and I would give us
> virtually no testing of new-feature-branch (since most developers just live
> on "master").

If we allow committing of "any new code" to master, how do we determine what
should go into 25.2? I think the only reasonable answer to that question would
be that master should become 26, which I'm not ready for yet. 25.x should go
through a few more rounds of stabilization before we jump on 26 features.

Thus, commits on master are commits toward the next release, which in this
case will be 25.2, and so shouldn't change APIs.

I'm fine with the creation of a "next" branch to accumulate 26 features that
either don't deserve a feature branch, or where the committer doesn't want to
create a separate feature branch. However, developers wouldn't focus on that
branch, but rather keep to emacs-25 and master. The majority of us shouldn't
be worrying about 26 yet.

To reiterate:

    emacs-25        pre-release branch for upcoming release (now 25.1)
    master          development branch for next release (now 25.2)
    "next"          general home for breaking, future work (now 26.1)

Having a two branch system means either not having a place for 25.2 work while
we focus on 25.1, or it means not having a place for 26 work other than
separate feature branches. Given that 26 is further away, I'm more concerned
about the stability of the former, rather than the latter. So whether people
want a "next" branch is up to you guys; topic branches are fine too.

To clarify an earlier statement: If there is work presently on master that
breaks APIs, please either provide a justification here on emacs-devel, or
cherry-pick that patch to "next" or some topic branch, and revert it from
master with a note that it doesn't belong in 25.2.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]