From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode Date: Thu, 31 Aug 2023 13:20:54 +0300 Message-ID: <83edjjecmx.fsf@gnu.org> References: <87il9kksqz.fsf@dfreeman.email> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87wmxj27fn.fsf@dfreeman.email> <831qfrptiq.fsf@gnu.org> <57429221-d9be-5791-e975-b3539905e2f6@gutov.dev> <83a5udlj47.fsf@gnu.org> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <87il90znco.fsf@yahoo.com> <1977fbef-307b-bcf4-9448-64f26916dd65@gutov.dev> <87edjozlqq.fsf@yahoo.com> <43ddad10-49dd-1c49-ebfe-51689780b315@gutov.dev> <83jztgk410.fsf@gnu.org> <83edjojx8c.fsf@gnu.org> <8734zzv7vk.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25031"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 31 12:22:16 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qbeoa-0006JF-FT for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Aug 2023 12:22:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbeoJ-0005ok-B1; Thu, 31 Aug 2023 06:22:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbeoG-0005kb-EL for emacs-devel@gnu.org; Thu, 31 Aug 2023 06:21:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbeoF-00070I-VU; Thu, 31 Aug 2023 06:21:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dn4Ga74gdeIve65GHX9Y8qhr6b+RKi5lrRImpD27ick=; b=bOJVlu33qTpG hap/I0OpZMwueHm6+7wIkRyGhedqqy9CyMZ5Fj9/F/efgL8UT1jhE/beqV6ws5xz2dYgRf5GJFydP ynWPavCYCKmK6n0/JHc1d7yzV8BpDJzaiuXfHAsdJIVWaI6Ky3+c8jwb1mEslgqZz44obnXrTb8wo wwSgLli3Jdd1Ii9ZIi6cfmGrRC9Fi4lWg9fpNnL/kguVs2zTjJEPY+Z6iSJ3R0nptjGUwNoh2/K14 oAFTglBnCjxYyAzsQe1YanRAkOWxwN3v7rtwPeVdp2Tyqqafaunl+kqdxT5U3iO3RSS9XLjebxcVM QvOCLMBO4eq3aYcp5+MCcQ==; In-Reply-To: <8734zzv7vk.fsf@localhost> (message from Ihor Radchenko on Thu, 31 Aug 2023 10:11:43 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309613 Archived-At: > From: Ihor Radchenko > Cc: Stefan Kangas , dmitry@gutov.dev, > luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email, > emacs-devel@gnu.org, manuel.uberti@inventati.org > Date: Thu, 31 Aug 2023 10:11:43 +0000 > > Eli Zaretskii writes: > > >> This seems to speak in favor of more frequent minor releases. > > > > I don't see how. We need to look for the reports about regressions in > > the previous release, and when we think we have seen enough, make a > > minor release. If feedback takes months to get to us, we either > > release blind with the same regressions (about which we haven't heard > > yet), or wait longer. > > Is there any downside holding on a minor release if _some_ bugs are > already fixed, even if others are not yet? What would be the point? People who want something like that can simply build the Git release branch, where we fix bugs every few days. A minor release is more than just code with some bugs fixed: it (a) has no known bugs except those whose fix is too risky, and (b) was tested in the wild during a pretest. > What I recently did for Org's bugfix releases was: > 1. Every two weeks I see if some bug fixes landed on bugfix branch > 2. If there are, I just tag a bugfix release If all you do is tag a commit, then that's not what constitutes a minor release in Emacs. We do much more than just tagging.