Releasing small, not critical features as bugfixes

Releasing small, not critical features as bugfixes

[emacsq]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

I checked if show-paren can show context from off screen and it can, in Emacs 29:

*** New user option 'show-paren-context-when-offscreen'.

When non-nil, if the point is in a closing delimiter and the opening

delimiter is offscreen, shows some context around the opening
delimiter in the echo area.

Emacs 28.1 was just released. Judging from the previous release history Emacs 29 is 1.5/2 years away.

Such small, useful improvements which don't cause critical errors could be released along with Emacs 28 bugfixes, so users can get them earlier, instead of waiting for them for two years.

Of course, there are bigger, more complex improvements which have to be tested thoroughly, but features like the above could be released sooner with the bugfixes, because they are pretty safe improvements.

Or maybe there could be a branch like emacs-future where these small useful improvements could be put, so there is the stable banch (28), this low risk future branch (between 28 and 29) and the bleeding edge (29).

[-- Attachment #2: Type: text/html, Size: 2739 bytes --]

Re: Releasing small, not critical features as bugfixes

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> Emacs 28.1 was just released. Judging from the previous release
> history Emacs 29 is 1.5/2 years away.
>
> Such small, useful improvements which don't cause critical errors
> could be released along with Emacs 28 bugfixes, so users can get them
> earlier, instead of waiting for them for two years.
>
> Of course, there are bigger, more complex improvements which have to
> be tested thoroughly, but features like the above could be released
> sooner with the bugfixes, because they are pretty safe improvements.

Famous last words.  You'd be surprised at how much trouble seemingly
innoculous changes can cause.

> Or maybe there could be a branch like emacs-future where these small
> useful improvements could be put, so there is the stable banch (28),
> this low risk future branch (between 28 and 29) and the bleeding edge
> (29).

So that means we will have 3 branches actively diverging at the same
time.  Who will do the merges in between?

I think we already have enough trouble keeping the two actively
developed branches synchronized.  (When was the last time emacs-28 was
merged to master, for example?)

Adding a third to the mix is just asking for trouble, IMHO.

Thanks.

Re: Releasing small, not critical features as bugfixes

[emacsq]

>
> Famous last words. You'd be surprised at how much trouble seemingly
> innoculous changes can cause.

A change in show paren, for example, has some risk, but much less risk than changes in native compilation, for example.

People using this lower risk future branch would know they still use a testing branch, so they would expect occasional hiccups, of course.

> So that means we will have 3 branches actively diverging at the same
> time. Who will do the merges in between?

Code committers could tag their commits with some marker like "low risk" or such if they know their commits can work well as separate changes and and automatic process could merge these tagged changes automatically into this low risk future branch.

So practically this branch could be kept up to date automatically by a script, there would be no additional work for developers aside from optionally marking commits for this low risk branch if they think their changes can also go for early release.

Re: Releasing small, not critical features as bugfixes

[Corwin Brust]

On Sun, Apr 10, 2022 at 11:38 AM emacsq <laszlomail@protonmail.com> wrote:
>
> So practically this branch could be kept up to date automatically by a script, there would be no additional work for developers aside from optionally marking commits for this low risk branch if they think their changes can also go for early release.
>

If your goal is to convince Emacs developers that it would be a small
amount of effort to maintain a separate branch that is Release plus
"simple improvements and fixes from trunk", perhaps creating a "fork"
that introduces the proposed new branch could be a way to demonstrate
that it is "low risk" and "no additional work".

Re: Releasing small, not critical features as bugfixes

[emacsq]

>
> If your goal is to convince Emacs developers

My goal was just floating this idea for discussion, because I as user see value in releasing small quality of life improvements in Emacs sooner than the usual 2-year cycle.

In the end it is up to emacs developers who contribute code to core emacs to decide if they see value in it, because they are the ones who can judge which commits are suitable for such earlier release, and if the extra decision required is worth the effort.

Re: Releasing small, not critical features as bugfixes

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> A change in show paren, for example, has some risk, but much less risk
> than changes in native compilation, for example.
>
> People using this lower risk future branch would know they still use a
> testing branch, so they would expect occasional hiccups, of course.

A feature as low risk as changing a few lines in `shell-resync-dirs' for
it to handle whitespace was recently discovered to cause hangs.  What
would happen with an infinitely larger feature such as the change in
show-paren to display offscreen context?

> Code committers could tag their commits with some marker like "low
> risk" or such if they know their commits can work well as separate
> changes and and automatic process could merge these tagged changes
> automatically into this low risk future branch.

I would want to see such an automatic process.  Would you please work on
it?  That should make it possible to automatically merge emacs-28 to
master as well.

Thanks.