Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Jonas Hahnfeld]

Am Samstag, dem 15.05.2021 um 17:30 +0200 schrieb Jean Abou Samra:
> Le 15/05/2021 à 17:02, Jonas Hahnfeld a écrit :
> > Yes, all 64-bit. For macOS, it's x86_64 only and not arm64 (Apple M1).
> > I'm optimistic that it should work with the same approach, but I have
> > to use GitHub Actions because I don't have access to a suitable macOS
> > otherwise, and as far as I know they don't have that type of machines
> > yet...
> 
> Understood. At any rate, any type of Mac OS 64-bit compilation gets
> us out of the Catalina morass.
> 
> As far as I understand, what is needed at this point is:
> 
> - improving Guile 2 support,
> 
> - setting up a release team with people running GNU/Linux and
>    Mac OS, or some kind of remote builder for Mac OS, to do the
>    regular releases.
> 
> Is this correct?

Ho, not so fast. If we want to go along the lines of my ideas, I think
we first want a "final" version of the system in the repository. The
reason I don't want this in a second repository, as we have with GUB
right now, is that keeping it versioned with LilyPond will ease future
upgrades. In particular, the scripts would be frozen along with stable
branches which makes minor releases much easier. Getting there will
first require some decisions, such as "non-full" packages (they make
reproducing issues in the scripts harder, but have the advantage of
being smaller) and packages for FreeBSD (it was natural to do for me
because it adds a second platform that I can test locally; and some
aspects are very similar to macOS, which helped a lot later on).

Then the "final" version will either be a rewrite in Python, or much
love to the current set of shell scripts to properly fix a few issues
that I'm already aware of. To give one example, the "gs" executable
currently lives in the bin/ directory, which is very bad if users want
to add that to their PATH. But there are other things that I've learned
and would like to get "right" before calling the job done.

Afterwards, it would be possible to produce official binaries from
existing releases (where the two points come in that you mentioned
above), but fully replacing GUB will require solutions to more topics:
We need a way to create tarballs for releases (probably a job for a
Docker container). From that tarball, we need to compile and upload the
documentation (certainly a job for another Docker container). And GUB
currently also generates regression test differences between releases,
that I personally think we don't need anymore. Note that if you didn't
know that this existed, and nobody noticed that the tests for 2.22.1
compare against the wrong baseline, that should be another reason to
not "port" it to the new system.

Does that make sense?
Jonas

signature.asc
Description: This is a digitally signed message part