Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>, 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 <eliz@gnu.org> 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.