From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Herring, Davis" Newsgroups: gmane.emacs.devel Subject: RE: Issues marked as fixed in 25.2 Date: Tue, 15 Nov 2016 06:25:00 +0000 Message-ID: References: ,<83r36dh10a.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1479191145 31597 195.159.176.226 (15 Nov 2016 06:25:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2016 06:25:45 +0000 (UTC) Cc: "rgm@gnu.org" , "emacs-devel@gnu.org" To: Eli Zaretskii , John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 15 07:25:41 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6XBG-0004k4-HT for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2016 07:25:18 +0100 Original-Received: from localhost ([::1]:44465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6XBJ-0000zj-NP for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2016 01:25:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6XB7-0000vg-9h for emacs-devel@gnu.org; Tue, 15 Nov 2016 01:25:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6XB3-0002qe-Bx for emacs-devel@gnu.org; Tue, 15 Nov 2016 01:25:09 -0500 Original-Received: from proofpoint4.lanl.gov ([2001:400:4210:400::a4]:37451) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6XB3-0002q2-1P; Tue, 15 Nov 2016 01:25:05 -0500 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate4.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id uAF6P0K6003635; Mon, 14 Nov 2016 23:25:01 -0700 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id E3AE61430A3B; Mon, 14 Nov 2016 23:25:00 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from ECS-EXG-P-CH01.win.lanl.gov (ecs-exg-p-ch01.win.lanl.gov [128.165.106.11]) by mailrelay1.lanl.gov (Postfix) with ESMTP id CED5D1430A32; Mon, 14 Nov 2016 23:25:00 -0700 (MST) Original-Received: from ECS-EXG-P-MB01.win.lanl.gov ([169.254.1.24]) by ECS-EXG-P-CH01.win.lanl.gov ([128.165.106.11]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 23:25:00 -0700 Thread-Topic: Issues marked as fixed in 25.2 Thread-Index: AQHSOflrlzmLHvabQU6uVsNt+fEgyaDPgYjJgAgfYxmAAXCGsoAAXGNVgAAYlOk= In-Reply-To: <83r36dh10a.fsf@gnu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.165.106.111] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.154, 1.0.3, 0.0.0000 definitions=2016-11-15_03:2016-11-11, 2016-11-15, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2001:400:4210:400::a4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209410 Archived-At: > I think the idea that we can know which version will come from what=0A= > branch is a fallacy, because the original intent can always be=0A= > thwarted by later decisions, based on situations no one can predict.=0A= =0A= That's why the three branches should not literally be "(current release tar= get, next minor, next major)". For a library equipped with an soname, the = standard versioning system suggests (bug fixes, new features, incompatible = changes). The same idea can be applied to a gradually evolving editor: com= mits are not assigned to a supposedly certain destiny, but rather are sorte= d according to the probability that they might delay a release.=0A= =0A= Then, whenever a "minimal changes" release is desired (e.g., to fix a vulne= rability without breaking other things), it can be made immediately from th= e strictest branch. When work on a major feature drags on, meaningful rele= ases can be made without it by releasing from the middle branch. (These tw= o use cases are the reason for the number of branches being 3; the match wi= th libraries is largely coincidental.) When instead release day comes for = the middle branch before the strict branch, you just merge the latter into = the former first.=0A= =0A= There are two refinements to make. First, the "strictness" of a branch has= two interpretations: either in terms of the user-visible behavior changes,= or in terms of the (possibly destabilizing) code changes. The former is m= ore appropriate for the library case, because feature lists and backwards-c= ompatibility guarantees are defined in terms of the visible behavior. It a= lso has the advantage of tending to reduce merge conflicts and cherrypickin= g, because refactoring can be done on the bugfix branch even if it is to su= pport new features to be added elsewhere. The latter interpretation may ho= wever be more appropriate for Emacs, where no absolute definition of compat= ibility exists but stability is very important.=0A= =0A= The second refinement is just (the bikeshedding of) what to call such branc= hes for Emacs, with a mind to making it easy for committers to categorize c= ommits. The schema that seems most obvious to me is (bug fixes and documen= tation work, well-separable features, core features) which maps well to the= past "major version features" (like lexical binding and modules). The fir= st two are often distinguished by whether a change includes NEWS text.=0A= =0A= Finally, you can still have feature branches, as we already do; this scheme= just reduces the anxiety associated with the merge of such a branch by all= owing it to remain targeted at an unspecified release.=0A= =0A= Davis=0A=