From: Marnen Laibow-Koser <[email protected]> Date: Sunday, March 8, 2020 at 4:16 PM To: Carl Sorensen <[email protected]> Cc: LilyPond <[email protected]>, Phil Holmes <[email protected]> Subject: Re: Linking 64-bit Mac builds from website
On Sun, Mar 8, 2020 at 6:06 PM Carl Sorensen <[email protected]<mailto:[email protected]>> wrote: On 3/8/20, 3:30 PM, "lilypond-devel on behalf of Marnen Laibow-Koser" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: [...] Wouldn’t they all be triggered off the same Git event? It seems to me that nightly (or git commit related) builds would have the version of the *next* unstable release. Why do you think that? It’s one possibility, sure, but there are others. I haven’t done the research yet to know which option makes sense here. Because right now we don’t have nightly builds, only released versions periodically. Unless we simultaneously revised the rest of our process, OSX 64 would be handled differently. I wouldn’t think we want to drive the difference. So a script on Marnen's site that builds an app bundle and uploads it to lilypond.org<http://lilypond.org> would have the release already on the website *before* the GUB build was released. Meaning the GUB build of the next version that wouldn’t even exist yet? GUB build of the next version would exist as a build from master, but it’s not a released version. At least it’s my understanding of how the current system works. However, this file wouldn't be linked anywhere on the website, so nobody would have a link to it (although, I guess they could guess what it is, since it has a known name structure). If I were to upload it, I’d make sure there was a link of some sort to it. Otherwise what’s the point? To have an automated system that does the CI, even when a version isn’t released. To lay a foundation for future build system automation. When an official release is made, the already-existing file is on lilypond.org<http://lilypond.org>. And the next periodic build from Marnen's site would be for the *next* unstable version. I don’t see how this follows from anything I’ve said... Because master is always ahead of unstable. When we release an unstable version, we bump the version number in master (to one past the current unstable release). That’s the way the release process works, as I understand it. So I'm in favor of * Giving Marnen's CI site access to upload files at lilypond.org<http://lilypond.org> (Small quibble: ideally, this will soon be the LilyPond project’s CI site, not ‘mine’. I really don’t want to be the sole person in charge of this.) OK, no complaints here. But it’s the LilyPond project’s CI site for OSX-64 builds only, at least right now, IIUC. * Using CI to provide regular upload to lilypond.org<http://lilypond.org> of the *next* stable version of lilypond. What do you mean by “next stable version”? I meant “unstable”, not stable. Also, I'm in favor of automating Marnen's process as a test for future possible automation that doesn't use GUB. Marnen, thank you so much for developing the lilypond .app bundle! I need that to be able to use multiple versions of lilypond with Frescobaldi on OSX. I'm really happy that you've done this work! You’re most welcome! Interesting point about multiple versions; some package managers support that use case and some do not. But .app bundles always trivially support it. That’s the main reason I was so excited to see your app bundle, in contrast to the MacPorts build. Thanks, Carl
