From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Issues marked as fixed in 25.2 Date: Tue, 15 Nov 2016 17:25:07 +0200 Message-ID: <83lgwkhijw.fsf@gnu.org> References: ,<83r36dh10a.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1479223572 18702 195.159.176.226 (15 Nov 2016 15:26:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2016 15:26:12 +0000 (UTC) Cc: jwiegley@gmail.com, emacs-devel@gnu.org, rgm@gnu.org To: "Herring\, Davis" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 15 16:26:08 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 1c6fc9-0000YE-09 for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2016 16:25:37 +0100 Original-Received: from localhost ([::1]:47011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6fcC-00064o-AA for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2016 10:25:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6fbW-00064V-LF for emacs-devel@gnu.org; Tue, 15 Nov 2016 10:24:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6fbS-0002P4-0A for emacs-devel@gnu.org; Tue, 15 Nov 2016 10:24:58 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6fbR-0002P0-Sx; Tue, 15 Nov 2016 10:24:53 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3047 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c6fbQ-0005Wc-TU; Tue, 15 Nov 2016 10:24:53 -0500 In-reply-to: (herring@lanl.gov) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209425 Archived-At: > From: "Herring, Davis" > CC: "rgm@gnu.org" , "emacs-devel@gnu.org" > Date: Tue, 15 Nov 2016 06:25:00 +0000 > > > I think the idea that we can know which version will come from what > > branch is a fallacy, because the original intent can always be > > thwarted by later decisions, based on situations no one can predict. > > That's why the three branches should not literally be "(current release target, > 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: commits are not > assigned to a supposedly certain destiny, but rather are sorted according to > the probability that they might delay a release. > > Then, whenever a "minimal changes" release is desired (e.g., to fix a > vulnerability without breaking other things), it can be made immediately from > the strictest branch. When work on a major feature drags on, meaningful > releases can be made without it by releasing from the middle branch. (These > two use cases are the reason for the number of branches being 3; the match with > 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. That's a different discussion, isn't it? The issue at hand is whether marking bugs at closure time as being "fixed in version X.Y" is something that can avoid the danger of having the specified version be eventually released without the fix, while the fix is actually available with some other released version. I submit that we cannot know in advance whether a given commit will end up in a specific released version. There are just too many factors that are unknown when the bug is resolved which could easily change the version in which the bug will be eventually fixed. Some of these factors: . a fix is found to be too dangerous for its branch, and is moved to another branch . a fix is found to be a "band-aid" type, and the real fix is on another branch . we decide to change the branch configuration And these are only the ones I came up with within the first 5 sec of thought. I don't see how _any_ branch configuration could prevent the above factors from thwarting our release plans as known when the bug is closed and marked as fixed in some specific version of Emacs.