Re: Linking 64-bit Mac builds from website

[Carl Sorensen]

From: Marnen Laibow-Koser <address@hidden>
Date: Sunday, March 8, 2020 at 4:16 PM
To: Carl Sorensen <address@hidden>
Cc: LilyPond <address@hidden>, Phil Holmes <address@hidden>
Subject: Re: Linking 64-bit Mac builds from website



On Sun, Mar 8, 2020 at 6:06 PM Carl Sorensen 
<address@hidden<mailto:address@hidden>> wrote:


On 3/8/20, 3:30 PM, "lilypond-devel on behalf of Marnen Laibow-Koser" 
<lilypond-devel-bounces+c_sorensen=address@hidden<mailto:address@hidden> on 
behalf of address@hidden<mailto:address@hidden>> 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