Re: Tramp as ELPA package

[Stefan Monnier <monnier@iro.umontreal.ca>]

> * Revised version structure. Tramp is released roughly every 6 months
>   (releases 2.4.0, 2.4.1, ...). In the time between, it has an
>   intermediate release string like 2.4.1-pre. At least for the *-pre
>   version, Tramp changes frequently, w/o a new version. This does not
>   work well for ELPA packages.

To the extent that the *-pre aren't distributed IIUC, I'm not sure what
problem would be caused by simply keeping the version string at "2.4.0"
instead of "2.4.1-pre".

>   Maybe we need an intermediate release string as the MELPA packages
>   have: add a time stamp in the Version: header of tramp.el *only* in
>   the Emacs repository, whenever a new version of Tramp shall appear as
>   package, like 2.4.1.pre.20180826. This shouldn't be done
>   automatically, by intention only. An automatic release of Tramp as
>   ELPA package might be too frequent, I fear.

I don't understand: GNU ELPA packages are only created when the
Version: changes, so it's only as frequent as you choose it to be.

> * Several Tramp versions. I maintain several Tramp versions in parallel,
>   currently 2.3.4 and 2.4.1.  I'm not confident that 2.4.1 shall be the
>   ELPA package today, because new features will be added here, and it is
>   kind of unstable, therefore.  I believe, 2.3.4 would be better suited
>   for all users *not* running Emacs 27.0.50.  Users running Emacs 27.0.50
>   do not need Tramp as ELPA package, because it is always synced with
>   the Emacs repository.  How do we manage this?

We don't.  Org-mode is in the same situation.

All other packages (including Emacs itself, BTW) far only have one
"active" release, basically.

There could be various ways to try and handle that, of course, but
someone would have to work on the elpa.git's admin/* scripts to
implement that kind of support.

IIUC the multiple-releases dance is mostly out-of-fashion in these days
of "DevOps".

> * Providing Tramp documentation. IIUC, ELPA packages could contain
>   *.texi and *.info files, but they are not propagated to the
>   users. This shall be enhanced, because new features of Tramp are
>   reflected there.

The .info files are "propagated to the users", but the .texi files
indeed are currently left unused.  I had plans to add a "make" step to
the way packages are built on elpa.gnu.org (so .info files could be
built from the corresponding .texi files, for example), but my attempts
to get a lightweight LXC container working on elpa.gnu.org have not been
successful yet.  I'm not very experienced in this kind of sysadmin work,
so if someone can help, that'd be great.


        Stefan