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
