Re: Support of older Emacs versions

[John Stoffel]

>>>>> "Mark" == Mark Diekhans <markd@ucsc.edu> writes:

> How about we create a viewmail-dev list that anyone
> can subscribe to?  That address both issues.

Sure, that addresses that issue for those who aren't interested in
getting VM moving again as a project.

> Göran Uddeborg <goeran@uddeborg.se> writes:
>> I'm adding the new "maintainers" list, but for now keep the "info"
>> list too as non-maintainer users might want to chime in here.
>> 
>> Mark Diekhans wrote:
>> > John Stoffel <john@stoffel.org> writes:
>> > > I suspect we should just got with debian 11 as our base, along with
>> > > Ubuntu 20.04 LTS, if it's still accepting updates. If not... let's
>> > > push to whatever the lowest emacs version is currently shipped on
>> > > current stuff.
>> > >
>> > > Unless someone else has a better idea?
>> > 
>> > sounds very reasonable, I have no better idea.
>> 
>> I would question if we need to go back even that far. Isn't it good
>> enough to support the current version of emacs, i.e. 29 right now, for
>> any new versions of VM.

So I'm running debian 12 and the current version of emacs is 28, so I
do think we should try to support back one more version of Debian if
it's not going to be a big problem.  

>> I live mostly in the Fedora world, but I understand both Debian 11 and
>> Ubuntu 20.04 are old. Would the packager for those distributions
>> really update VM? Without emacs itself being updated? That is not how I
>> package for Fedora; the latest and/or upcoming release gets the latest
>> VM, older stay where they are unless something actually breaks.

Good points, but doesn't Fedora update much more frequently that
Debian?  I was mostly trying to suggest that we don't need to support
anything older than emacs 24 or so, if that helps get the code base
cleaner and more supportable. 

>> If someone is using a distribution with an older emacs, then it
>> would make sense you use an older version of VM too. (At least as
>> far as new developments are concerned. If we would find e.g. a
>> security issue in VM, that would be another thing.)

Maybe?  I just don't want us to leave too many people in the dust, me
included.  I also don't get the impression that emacs is changing
_that_ fast either.  But I could be very very wrong.

>> Would this be too agressive? My goal is to keep the load on developers
>> as light as possible, in order to maximize the chance things get done.

Amen, this is certainly a good goal!