Re: Tramp as ELPA package

[Michael Albinus <michael.albinus@gmx.de>]

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

>> If the single place were in tramp.el instead of configure.ac you
>> wouldn't need tramp.el to be generated either.
>
> See patch below for an example.

Thanks. I've applied this to the repositories in your name. However,
this is the first step only. Further problems for making Tramp an ELPA
package:

* 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.

  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.

* 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?

* 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.

* Likely more problems ...

>         Stefan

Best regards, Michael.