emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Next release from master


From: Daniel Colascione
Subject: Re: Next release from master
Date: Wed, 10 Feb 2016 19:47:10 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 02/10/2016 10:06 AM, Óscar Fuentes wrote:
> John Wiegley <address@hidden> writes:
> 
>> Not "open open", no.  It's open for features and changes compatible with 
>> 25.1,
>> but too new to be accepted in 25.1.
> 
> Why the dot releases have new features and non-bug-fixing changes at
> all? What's the criteria for putting a new feature on a dot release and
> another on a major release?

It's partially because of this confusion that I think we should give up
on the major-minor release system entirely. That system made a lot more
sense when bandwidth was scarce, disk space was precious, compilation
glacial, and package management manual. These days, we have ample
computing resources. I'd like to seriously consider time-based releases
of master (say, every six months), with backports of only critical
security fixes to older releases --- with support for a maximum of, say,
three years. This model is becoming increasingly common for OS
distributions and major applications; Mozilla has used it successfully
for years.

While it's true that out-of-tree developers could no longer use version
numbers to understand when APIs might break, I don't think that's really
a problem, since they, too, can distribute their releases continuously.
I seldom bother with releases myself anymore: if I want to use a
package, I just clone the repository. I think a one-major-release
deprecation period for breaking changes would give out-of-tree
developers more than enough time to fix any broken packages.

With a time-based monolithic release system, we wouldn't have to worry
about what features could go in what branch. We'd instead only have to
worry about the length of time for which we would have to support
obsolete APIs, and IMHO, it's much easier to reason about contractual
guarantees at that level.

Quick time-based releases also help get new code in the hands of users
faster, which is not only better for Emacs users, but better for the
future community of Emacs developers, who would find it satisfying to be
able to see code reach production in a relatively short time.

While this scheme does place a greater burden on keeping master stable,
you're _already_ advocating the use of feature branches for potentially
disruptive work, so in theory, master should be stable already. In
practice, I run master synced at irregular intervals and seldom have
problems.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]