[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Making AUCTeX ELPA releases from the master branch
From: |
Tassilo Horn |
Subject: |
Making AUCTeX ELPA releases from the master branch |
Date: |
Tue, 09 Apr 2024 14:09:53 +0200 |
User-agent: |
mu4e 1.12.3; emacs 30.0.50 |
Hi all,
some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
AUCTeX ELPA release and asked why there were changes to files which
shouldn't be committed because they are generated from other files,
e.g., info files.
The reason is that at the time where we added AUCTeX to ELPA (and
created the externals/elpa branch for that purpose), the ELPA machinery
wasn't able to perform our normal build procedure. But Stefan Monnier
chimed in and suggested that nowadays, those issues are most probably
resolved or can be resolved in some less drastic way than a separate
branch. For example, building info manuals from multiple texi files
residing in subdirectories are no problem anymore (one can specify `:doc
("doc/auctex.texi" "doc/preview-latex.texi")` in the ELPA package
recipe) and we could have a separate elpa target in our Makefile and
specify that as `:make "elpa"` in package recipe.
I think it would be great if we could make it so that everyone of us
could trigger a new ELPA release directly from the master branch by just
incrementing the Version header which currently resides in auctex.el on
the externals/elpa branch but which is generated from auctex.el.in on
the master branch so not suitable for a Version header. But no problem,
the elpa recipe could specify some different `:main-file`.
So basically, I see these challenges:
- We set the AUCTeX/preview version and date in the texi files from
AUCTEXVERSION, AUCTEXDATE, PREVIEWVERSION, and PREVIEWDATE which are
guessed by autoconf from the ChangeLog.1 and ChangeLog-preview files
which arranges that the *VERSION is just the same as the *DATE if
the top entry in the ChangeLogs is not a release entry in which case
the version is extracted there.
These ChangeLogs aren't usually edited. Currently, the tarball
release process prepends the changes since the last tarball release,
and then the "release manager" (Mosè) adds an entry like
--8<---------------cut here---------------start------------->8---
2024-01-17 Mosè Giordano <mose@gnu.org>
* Version 13.3 released.
--8<---------------cut here---------------end--------------->8---
on top. So how should that work for ELPA releases?
- There's also a completely different alternative: make the
externals/elpa the new "main" branch and drop master and tarball
releases altogether. Is there still a justification for having
them? I mean, we dropped XEmacs support anyway and it should be
easy enough for distros to just use the ELPA tarballs as basis for
their distro packages.
- Mostly to Stefan: How can we test that safely? I guess we'll find
some more issues. I don't want to edit the AUCTeX recipe in
elpa-packages and then deploy broken packages to users.
Bye,
Tassilo
- Making AUCTeX ELPA releases from the master branch,
Tassilo Horn <=
- Re: Making AUCTeX ELPA releases from the master branch, Stefan Monnier, 2024/04/09
- Re: Making AUCTeX ELPA releases from the master branch, Tassilo Horn, 2024/04/10
- Re: Making AUCTeX ELPA releases from the master branch, Stefan Monnier, 2024/04/10
- Re: Making AUCTeX ELPA releases from the master branch, Tassilo Horn, 2024/04/10
- Re: Making AUCTeX ELPA releases from the master branch, Stefan Monnier, 2024/04/10
- Re: Making AUCTeX ELPA releases from the master branch, Stefan Monnier, 2024/04/10
- Re: Making AUCTeX ELPA releases from the master branch, Tassilo Horn, 2024/04/20
- Re: Making AUCTeX ELPA releases from the master branch, Stefan Monnier, 2024/04/20
- Re: Making AUCTeX ELPA releases from the master branch, Tassilo Horn, 2024/04/20
- Re: Making AUCTeX ELPA releases from the master branch, Stefan Monnier, 2024/04/21