emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode
Date: Thu, 31 Aug 2023 13:51:08 +0300

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 10:32:07 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> For Org, a number of people just update from ELPA. Releasing benefits
> these users. 

I don't see how is that different from updating from Git.

> > 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.
> 
> You are right. To clarify: I am talking about _bugfix_ releases. Like
> Org 9.6.7 -> 9.6.8. Emacs does not have those, currently.

If bugfix releases just fix bugs, then basically every commit on the
release branch is such a "release", because we only fix bugs there.

And don't forget that minor releases affect downstream distros: they
need to package a new release, patch it, announce it, manage it, etc.
It's very different from a single package, even a package that is as
large as Org.

> >> 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.
> 
> So, what about "bugfix" releases? AFAIU, it is mostly producing a
> release tarball + waiting for Emacs to be packaged on major GNU/Linux
> distributions. The timing would be anything acceptable for the latter
> task, which appears to be a bottleneck in such scenario.

That has only disadvantages from my POV: 2 hours of work to produce
and test a tarball with no benefits at all.  If someone wants to
volunteer to do that, fine.  (But then making a tarball by following
the instructions in make-tarball.txt is easy, and anyone can do that
for themselves if they want to.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]