Unofficial LilyPond version for macOS Catalina #39
Conversation
|
For future reference, it's inefficient to close and open new pull requests for the same changes. Now, all you would need is |
Casks/lilypond-unofficial.rb
Outdated
| url "https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-#{version}.build20200311175017-darwin-64.tar.gz" | ||
| appcast 'https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.20.0#release' |
There was a problem hiding this comment.
On line 2, you declare version '2.20.0'. However, I would hazard to guess (and @marnen can correct me if I'm wrong) that the build number (currently 20200311175017) would normally change more often than the patch number. When I tried my hand at creating a cask for this, I declared version '2.20.0.build20200311175017', but then I found a way that I think is even better because it allows the part of the version number before the build number to be used in one more place.
There was a problem hiding this comment.
@fanninpm Thank you very much for this tip. I correct right away.
However, I did not understand the EL_NOMBRE_DE_SU_RAMA.
There was a problem hiding this comment.
It seems from my latest push that you got the gist of what I meant by LE_NOME_DE_VOTER_BRANCH, but it's currently late at night where I am.
You may want to add the version number to the appcast string (but I would personally hold off from doing that until the maintainer comes by to comment that this is the correct way to go).
There was a problem hiding this comment.
However, I would hazard to guess (and @marnen can correct me if I'm wrong) that the build number (currently 20200311175017) would normally change more often than the patch number.
That's generally correct, although at this point, they may change at the same rate. I originally had the build number in there because I had to develop a new build process for 64-bit Mac builds, and since I might build the same source code with several different attempts at a Makefile that worked, it made sense to have a build number so I could track which version of the Makefile had been used for which build.
Now that the Makefile more or less works, the build number won't change that often (probably just when I actually build from a new version of the source, or when the Makefile requires major changes).
Casks/lilypond-unofficial.rb
Outdated
| @@ -0,0 +1,45 @@ | |||
| cask 'lilypond-unofficial' do | |||
There was a problem hiding this comment.
How about lilypond-64-bit or something like that?
There was a problem hiding this comment.
The file would also have to be renamed, and that would most likely involve git mv OLD_FILE_NAME NEW_FILE_NAME.
There was a problem hiding this comment.
Ok, cask renamed,
What do you want more ?
|
|
||
| # bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond- was verified as official when first introduced to the cask | ||
| url "https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-#{version.before_comma}.build#{version.after_comma}-darwin-64.tar.gz" | ||
| appcast 'https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.20.0#release' |
There was a problem hiding this comment.
This could mention the #{version.before_comma} (but make sure to put it in double quotes if you do that).
The official cask try for macOS Mojave, this cask repare that !
With appcast as requested by @fanninpm