bug#60990: 29.0.60; New seq release 2.24

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

The seq package has seen multiple additions since the seq 2.23 release.
Would it be possible to release a new version 2.24 and bump the version
in Emacs 29? With such a seq release 2.24, which coincides with Emacs 29,
packages depending 2.24 would not pull in the additional package if
installed on Emacs 29.

In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2023-01-14 built on projects
Repository revision: 8d7ad65665833ae99b7e7119dae37afa438968a4
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

bug#60990: 29.0.60; New seq release 2.24

[Stefan Kangas]

Version: 29.2

Daniel Mendler <mail@daniel-mendler.de> writes:

> The seq package has seen multiple additions since the seq 2.23 release.
> Would it be possible to release a new version 2.24 and bump the version
> in Emacs 29? With such a seq release 2.24, which coincides with Emacs 29,
> packages depending 2.24 would not pull in the additional package if
> installed on Emacs 29.
>
> In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
>  version 1.16.0, Xaw scroll bars) of 2023-01-14 built on projects
> Repository revision: 8d7ad65665833ae99b7e7119dae37afa438968a4
> Repository branch: emacs-29
> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
> System Description: Debian GNU/Linux 11 (bullseye)

It seems we dropped the ball here and released Emacs 29.1 with seq.el
versioned as 2.23.  I've now bumped the seq version to 2.24, so that we
won't have the same problem in Emacs 29.2.

With that, I'm closing this bug report.

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

Hello Stefan,

can we also get a new seq release 2.24 on ELPA? My report was about both
tagging a new seq version in Emacs and a new release on ELPA. Thanks!

Daniel

On 9/4/23 17:32, Stefan Kangas wrote:
> Version: 29.2
> 
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> The seq package has seen multiple additions since the seq 2.23 release.
>> Would it be possible to release a new version 2.24 and bump the version
>> in Emacs 29? With such a seq release 2.24, which coincides with Emacs 29,
>> packages depending 2.24 would not pull in the additional package if
>> installed on Emacs 29.
>>
>> In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
>>  version 1.16.0, Xaw scroll bars) of 2023-01-14 built on projects
>> Repository revision: 8d7ad65665833ae99b7e7119dae37afa438968a4
>> Repository branch: emacs-29
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
>> System Description: Debian GNU/Linux 11 (bullseye)
> 
> It seems we dropped the ball here and released Emacs 29.1 with seq.el
> versioned as 2.23.  I've now bumped the seq version to 2.24, so that we
> won't have the same problem in Emacs 29.2.
> 
> With that, I'm closing this bug report.

bug#60990: 29.0.60; New seq release 2.24

[Stefan Kangas]

Daniel Mendler <mail@daniel-mendler.de> writes:

> Hello Stefan,
>
> can we also get a new seq release 2.24 on ELPA? My report was about both
> tagging a new seq version in Emacs and a new release on ELPA. Thanks!

Yes, it will be released on GNU ELPA automatically by the GNU ELPA once
emacs-29 is merged to master.

Unfortunately, users of Emacs 29.1 will be able to "upgrade" to the
identical version in GNU ELPA.

Users of Emacs 29.2 will not have that problem, though.

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/4/23 19:05, Stefan Kangas wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> Hello Stefan,
>>
>> can we also get a new seq release 2.24 on ELPA? My report was about both
>> tagging a new seq version in Emacs and a new release on ELPA. Thanks!
> 
> Yes, it will be released on GNU ELPA automatically by the GNU ELPA once
> emacs-29 is merged to master.
> 
> Unfortunately, users of Emacs 29.1 will be able to "upgrade" to the
> identical version in GNU ELPA.
> 
> Users of Emacs 29.2 will not have that problem, though.

How is that? I thought that seq is not a :core package, since it
supports Emacs versions from before the introduction of cl-defgeneric.
It has different code which must be updated manually and as such doesn't
automatically get released.

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Stefan Kangas]

Daniel Mendler <mail@daniel-mendler.de> writes:

> How is that? I thought that seq is not a :core package, since it
> supports Emacs versions from before the introduction of cl-defgeneric.
> It has different code which must be updated manually and as such doesn't
> automatically get released.

Uhm, yes, you're right of course.

I have now merged all the changes from master/emacs-29 (the branches are
identical), and pushed it to elpa.git.

I only saw `take' that needed an compatibility alias, and the rest of
the changes should be fine on older versions.  Testing on Emacs 25 would
be much appreciated, though.

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/4/23 20:35, Stefan Kangas wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> How is that? I thought that seq is not a :core package, since it
>> supports Emacs versions from before the introduction of cl-defgeneric.
>> It has different code which must be updated manually and as such doesn't
>> automatically get released.
> 
> Uhm, yes, you're right of course.
> 
> I have now merged all the changes from master/emacs-29 (the branches are
> identical), and pushed it to elpa.git.

Thanks! Btw, it seems that seq 2.24 is the last version which can be
distributed via ELPA since Emacs 29 preloads seq. If Emacs 30 comes with
a hypothetical new seq 2.30 with new functions, a package requiring seq
2.30 cannot load seq on Emacs 29, since the feature is already loaded.
We could possibly work around this problem by distributing seq functions
from than 2.30 and newer via Compat. We should then document that
packages needing a seq newer than 2.24 should rely on Compat instead. I
am not sure if this is a desired solution though since it might be a bit
confusing. I've added Philip and Stefan M. in cc. What do you think?

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Thanks! Btw, it seems that seq 2.24 is the last version which can be
> distributed via ELPA since Emacs 29 preloads seq.

Maybe it's OK to leave seq at 2.24 on ELPA.  The main purpose of putting
it up on ELPA was to encourage adoption and accommodate changes more
easily, but it's now mature enough that changes are fairly slow, so we
can now rely on "the usual" solutions to deal with compatibility issues,
I think.


        Stefan

bug#60990: 29.0.60; New seq release 2.24

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Thanks! Btw, it seems that seq 2.24 is the last version which can be
>> distributed via ELPA since Emacs 29 preloads seq.
>
> Maybe it's OK to leave seq at 2.24 on ELPA.  The main purpose of putting
> it up on ELPA was to encourage adoption and accommodate changes more
> easily, but it's now mature enough that changes are fairly slow, so we
> can now rely on "the usual" solutions to deal with compatibility issues,
> I think.

Sounds like a plan.

If no objections crop up, I'll document this decision in seq.el and bump
the Emacs 30.1 version to 2.25 once emacs-29 has been merged to master.

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/4/23 22:11, Stefan Monnier wrote:
>> Thanks! Btw, it seems that seq 2.24 is the last version which can be
>> distributed via ELPA since Emacs 29 preloads seq.
> 
> Maybe it's OK to leave seq at 2.24 on ELPA.  The main purpose of putting
> it up on ELPA was to encourage adoption and accommodate changes more
> easily, but it's now mature enough that changes are fairly slow, so we
> can now rely on "the usual" solutions to deal with compatibility issues,
> I think.

What do you see as '"the usual" solutions'? To be concrete, if new seq-*
functions are added in Emacs 30 do you consider it a viable solution if
we add backports to Compat or not? They would land in compat-30.el,
which is not yet part of the released Compat version.

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> What do you see as '"the usual" solutions'?

The solutions used when changes are made in `minibuffer.el`,
`simple.el`, `subr.el`, ...

E.g. using `fboundp`, testing `emacs-major-version`, ...

> To be concrete, if new seq-* functions are added in Emacs 30 do you
> consider it a viable solution if we add backports to Compat or not?

Can't see why not, yes (but I'm not sufficiently familiar with `compat`
to know if there might be some subtle issues).


        Stefan

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/5/23 00:20, Stefan Monnier wrote:
>> What do you see as '"the usual" solutions'?
> 
> The solutions used when changes are made in `minibuffer.el`,
> `simple.el`, `subr.el`, ...
> 
> E.g. using `fboundp`, testing `emacs-major-version`, ...

Okay, thanks! Makes sense. The goal of Compat is to reduce such feature
checks in packages, but if Compat is not used, fboundp is the way to go.

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/4/23 20:35, Stefan Kangas wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> How is that? I thought that seq is not a :core package, since it
>> supports Emacs versions from before the introduction of cl-defgeneric.
>> It has different code which must be updated manually and as such doesn't
>> automatically get released.
> 
> Uhm, yes, you're right of course.
> 
> I have now merged all the changes from master/emacs-29 (the branches are
> identical), and pushed it to elpa.git.
> 
> I only saw `take' that needed an compatibility alias, and the rest of
> the changes should be fine on older versions.  Testing on Emacs 25 would
> be much appreciated, though.

Hello Stefan,

I just looked at the seq repository and noticed that the new additions
(commit 9d9f51b0e3ca59e0a488801064512f4878ac910b, seq-split, seq-keep,
etc.) seem to be missing from the file seq-24.el, such that the
functionality of the package differs between Emacs 24 and Emacs 25 and
newer.

It is a bit unfortunate that the code has to be duplicated but it may be
a bit too early to drop Emacs 24 support from seq altogether? As another
example, for Compat we try to maintain compatibility with Emacs 24.4 and
newer for the time being. For Compat it hasn't been a big problem to
maintain support for 24.4. We didn't have to use the cl-defgeneric
functionality so far.

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Stefan Kangas]

Daniel Mendler <mail@daniel-mendler.de> writes:

> I just looked at the seq repository and noticed that the new additions
> (commit 9d9f51b0e3ca59e0a488801064512f4878ac910b, seq-split, seq-keep,
> etc.) seem to be missing from the file seq-24.el, such that the
> functionality of the package differs between Emacs 24 and Emacs 25 and
> newer.

Patches welcome, I think.

> It is a bit unfortunate that the code has to be duplicated but it may be
> a bit too early to drop Emacs 24 support from seq altogether?

There's no need to drop Emacs 24 support, but that support is still
useful even if it's not complete.

Packages that want to use the new stuff can also do that in the usual
ways, as Stefan M pointed out.

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/9/23 14:28, Stefan Kangas wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> I just looked at the seq repository and noticed that the new additions
>> (commit 9d9f51b0e3ca59e0a488801064512f4878ac910b, seq-split, seq-keep,
>> etc.) seem to be missing from the file seq-24.el, such that the
>> functionality of the package differs between Emacs 24 and Emacs 25 and
>> newer.
> 
> Patches welcome, I think.

Should I open a bug report to track this? Thanks!

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> It is a bit unfortunate that the code has to be duplicated but it may be
> a bit too early to drop Emacs 24 support from seq altogether?

In my experience, the better way to handle backward compatibility is in
a reactive rather than proactive way, especially when talking about
compatibility with 10 year old software.


        Stefan

bug#60990: 29.0.60; New seq release 2.24

[Daniel Mendler]

On 9/9/23 17:47, Stefan Monnier wrote:
>> It is a bit unfortunate that the code has to be duplicated but it may be
>> a bit too early to drop Emacs 24 support from seq altogether?
> 
> In my experience, the better way to handle backward compatibility is in
> a reactive rather than proactive way, especially when talking about
> compatibility with 10 year old software.

Actually I don't disagree. It looked as if the seq package aims to
provide all seq functions on all supported Emacs versions. Compat almost
fully supports 24.4 and newer, which works surprisingly well. Philip
initially even added support for 24.3 but this led to serious complications.

Daniel

bug#60990: 29.0.60; New seq release 2.24

[Stefan Kangas]

Daniel Mendler <mail@daniel-mendler.de> writes:

> Should I open a bug report to track this? Thanks!

I don't mind.  It might make more sense to wait for someone to ask for
it though, so that we know that there is a real need.