auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making AUCTeX ELPA releases from the master branch


From: Tassilo Horn
Subject: Re: Making AUCTeX ELPA releases from the master branch
Date: Wed, 10 Apr 2024 16:47:37 +0200
User-agent: mu4e 1.12.3; emacs 30.0.50

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

>> --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?
>
> For GNU ELPA releases,the "main" place where you keep version numbers
> should be your "main file", ideally `auctex.el`.
>
> So your make target will want to extract the version from there instead
> of from the ChangeLog.  But that should be easy.  The "right" way would
> be to fire an Emacs process and use `package-buffer-info` or just
> `lm-header` to fetch the info.  But I'd use a `sed` one-liner.
>
> That won't give you a date, tho.  You could try and use Git to find a
> corresponding date, but personally, I'd just use the current date
> instead.

Yes, something like this.

>>   - 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.
>
> That's what I'd do if I were you, indeed.  🙂

No objections from me.

> But note that this will still require tweaking the GNUmakefile to
> fetch the Version from the new place and a few things like that and
> changing the recipe to add something like `:make "elpa"`.

Yes, but I think getting that right would be much easier than adding
a similar target to the build infrastructure on master.

>>   - 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.
>
> You can also try and reproduce the build locally as follows:
>
>     git clone --single-branch https://git.sv.gnu.org/git/emacs/elpa
>     cd elpa
>     make                  # Setup the infrastructure
>     make packages/auctex  # Create a worktree of the package
>     make auctex.tar       # Build the tarballs into `auctex.tar`
>
> Note that the tarball is built from *the commit* rather than from the
> current set of files (i.e. we start with `git stash` and we `git clean`
> as well, IIRC, so be forewarned that it can throw away uncommitted data).

So just that I get it right, we'd do:

  - Make our former externals/elpa branch the new main branch
    - git checkout -b main externals/elpa && git push
  - Then clone elpa and setup the infrastructure as you said
  - Edit elpa-packages locally (but don't yet commit/push)
    - remove `:manual-sync t`
    - add `:branch "main"` and maybe `:make "elpa"`
  - Then "make packages/auctex" once
  - while (make auctex.tar is not satisfactory)
    - edit on our new main branch, e.g., refine the elpa target
  - commit and push the modifications to the auctex recipe in
    elpa-packages

Bye,
Tassilo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]