Provide compiles .so files in releases

[brunetton]

Hi

I wondered: is there any reason why yo do not provide complied .so files in releases ?

I forked the project to make an example of release with it: https://github.com/brunetton/Fluida.lv2/releases/tag/v0.7 (Fluida-0.7.lv2.zip)

[brummer10]

Hi I may add a workflow file to let github build a binary which then could be provided under the release tag, but implementing binary's in the source releases is out of scope.

[brunetton]

Hi I may add a workflow file to let github build a binary which then could be provided under the release tag, but implementing binary's in the source releases is out of scope.

Of course I'll never include compiled result in source code nor source git repo. It's something else here:

• when creating releases, Github automatically puts a zip snapshot version of current source code
• but you can manually (or automatically, if you release 20 compiled files every week) embed any file that are NOT part of the Git repo. This is used everywhere on Github for publishing releases.

Random examples:

• https://github.com/intel/compute-runtime/releases
• https://github.com/wagoodman/dive/releases
• https://github.com/prusa3d/PrusaSlicer/releases
• https://github.com/derailed/k9s/releases
• https://github.com/mifi/lossless-cut/releases
• https://github.com/arendst/Sonoff-Tasmota/releases
• https://github.com/3Dickulus/FragM/releases
• https://github.com/jean-emmanuel/open-stage-control/releases/

Doc: https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository (look to the number 8)

[brummer10]

• but you can manually (or automatically, if you release 20 compiled files every week) embed any file that are NOT part of the Git repo. This is used everywhere on Github for publishing releases.

Well, for fluida I need to upload a source tarball on release anyway, as the source upload by github didn't contain the submodules. What I mean is, when I add a binary to the releases, then I'll use a workflow github service like this one I use in a other project. https://github.com/brummer10/Rumor/blob/master/.github/workflows/build.yml That will automate the build and the upload and wont add any further work on me. As well I could build it this way on a selected distribution, or multiple ones, even a deb package would be possible, instead build it on my own debian/sid machine. That could prevent a lot issues for users with older distributions. You may port the script I posted above to fluida and check it out yourself, maybe you like to open a pull request then, that could make it work much faster.

[brunetton]

• but you can manually (or automatically, if you release 20 compiled files every week) embed any file that are NOT part of the Git repo. This is used everywhere on Github for publishing releases.

Well, for fluida I need to upload a source tarball on release anyway, as the source upload by github didn't contain the submodules.

I'm not sure why you want to do this as releases are not intended to get source but get the "working result". I'm sure 99.9% of peoples that comes here just wants to download the plugin and use it. If one dev want an older version (the 0.1%), he can just checkout repo on release tag.

What I mean is, when I add a binary to the releases, then I'll use a workflow github service like this one I use in a other project. https://github.com/brummer10/Rumor/blob/master/.github/workflows/build.yml That will automate the build and the upload and wont add any further work on me.

I'm aware of the Github worflow process; but there had been 3 Fluida releases on 1.3 years, that makes one release each 5.3 months on average. I don't thinks making a mouse drag'n drop one every 5 months is longer than implementing a Github release workflow process.

As well I could build it this way on a selected distribution, or multiple ones, even a deb package would be possible, instead build it on my own debian/sid machine. That could prevent a lot issues for users with older distributions. You may port the script I posted above to fluida and check it out yourself, maybe you like to open a pull request then, that could make it work much faster.

Personally, I wouldn't install a .deb package for a simple plugin. I prefer putting it on my ~/.lv2plugins dir.

Anyway for users do not have any choice than compiling .so file themselves; for 2 years now. What is the better for users (that just want to make music) ?

• being able to download and put the .so file in lv2 dir with all other LV2 plugins (100% of plugins I'm using are distributed as archives containing .so file and needed assets)
• having to compile themselves the binary (implies install compiling tools, knowing them, understand Git basics ...)

Just manually add assets once every 5 months, and make it automated when automatisation makes you gain time ! I'm sure this is not the case here.

Thanks for your time (surely more longer than having uploaded 3 artifacts since 2 years ;))

[brummer10]

I'm aware of the Github worflow process; but there had been 3 Fluida releases on 1.3 years, that makes one release each 5.3 months on average. I don't thinks making a mouse drag'n drop one every 5 months is longer than implementing a Github release workflow process.

The workflow file I mentioned above does a binary build on any commit, so this way we'll have a actual binary from the last source at any time. All what needs to be done is edit the repository name and the file name for the resulting zip file. As I said, I use debian/sid, when build on my machine it isn't said that it will work on others which running ubuntu or fedora.

Thanks for your time (surely more longer than having uploaded 3 artifacts since 2 years ;))

Ha, ha, well, that is true, so you want to push me to make a new release? Well, I'll consider that.

[brunetton]

I'm aware of the Github worflow process; but there had been 3 Fluida releases on 1.3 years, that makes one release each 5.3 months on average. I don't thinks making a mouse drag'n drop one every 5 months is longer than implementing a Github release workflow process.

The workflow file I mentioned above does a binary build on any commit, so this way we'll have a actual binary from the last source at any time.

This is indeed an argument on favor for automated process !

All what needs to be done is edit the repository name and the file name for the resulting zip file. As I said, I use debian/sid, when build on my machine it isn't said that it will work on others which running ubuntu or fedora.

Indeed; this is not perfect. But better than nothing ;)

Thanks for your time (surely more longer than having uploaded 3 artifacts since 2 years ;))

Ha, ha, well, that is true, so you want to push me to make a new release? Well, I'll consider that.

Indeed not really :) Just tried to push to publish a compiled binary from time to time (when there are "big" changes). Just saying that I think that it's better to do that instead of not publishing any "output" of the project; while waiting for the "perfect" solution that is automated release workflow !

Thanks again :)

[brummer10]

So here you go: https://github.com/brummer10/Fluida.lv2/releases/tag/Latest under that tag, from now on, the latest working git checkout will be available as binary. If that solve this issue, please close it. regards hermann

[brunetton]

Amazing :tada: !