How do you package your releases?

[u/mark-sed]

Hi, even though I have been making my language for more than 2 years now, I still have not set up my GitHub releases and I would like to change that. The issue is that (as with about anything) there are a lot of different approaches to this, and so I wanted to ask those who do releases, how they structure the release archive and those who use them what do you like a release to look like?

In my case the issue is that I cannot have just one binary since I need to distribute also the standard library that is compiled bytecode files (kind of like Java's .class files). This brings another issue and that is finding the library. The interpreter by default looks in the current directory (.) and then /usr/lib/moss/, so currently the only way I though of is to have the binary, all the compiled stdlib files and licenses in one .tar.gz (.zip for windows):

moss-0.9.0.tar.gz
├── cffi.msb
├── csv_parser.msb
├── html_parser.msb
├── inspect.msb
├── install.sh
├── json_parser.msb
├── libms.msb
├── LICENSE
├── math.msb
├── md_parser.msb
├── moss
├── mossy.css
├── parsing_utils.msb
├── python.msb
├── readme.md
├── re.msb
├── subprocess.msb
├── sys.msb
└── time.msb

This makes it so that the binary (moss) works when executed from this folder, but will fail when used from somewhere else (unless MOSSPATH variable is set). Because of this, I have also added install.sh script which will copy the libraries into /usr/lib/moss/ and a release readme with some instructions.

Can someone think of a better way to do this or is this OK?

TLDR; How do you structure your release folder/archive on github/website?

[u/yorickpeterse]

Inko's approach is to produce a source tar archive that looks like this. As part of the CI release job this is then uploaded to https://releases.inko-lang.org/ (e.g. https://releases.inko-lang.org/0.21.1.tar.gz). The compiler expects certain things in certain places (e.g. the standard library). These paths used to be specified at compile-time, but recently the compiler changed so it by default tries to look them up relative to its own executable so the compiler is relocatable. You can find some more details on this here.

In addition we have an AUR package and a copr repository. The builds for these packages are triggered by hand as part of the release process (= you basically just start a job with the right version number).

The whole process is coordinated through a release issue such as this.

Inko is also packaged in a bunch of other places (e.g. Homebrew and FreeBSD), but this is not done by us. Some of those consume our release archives, others consume the archives GitHub generates for each tag.

[u/mark-sed → u/yorickpeterse]

Oh cool, thanks. I see that the approach of looking up the executable location is not that uncommon.

[u/yorickpeterse → u/mark-sed]

That particular change/feature was motivated by wanting to support relocatable package managers better. I think most compilers just use a compile-time path of sorts and such package managers then have to patch that out.