On 02/10/2016 10:06 AM, Óscar Fuentes wrote: > John Wiegley 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.