Provide releases

[kpet]

We need to:

• [ ] Define a versioning scheme. I'm thinking of something date-based to avoid any possible confusion with OpenCL or Vulkan versions. vYYYY-MM-DD-NN with YYYY being the year, MM month, DD day and NN number of the release?
• [ ] Define passing criteria for a released version, i.e. a list of tests and configs that need to pass
  • [ ] Linux distributions (see #556)
  • [ ] Vulkan SDK versions
• [ ] Automate as much of the testing as possible, ideally all of it
• [ ] Create scripting for releases so they are made in a consistent way
• [ ] What else?

[stolk]

Any idea if at some point, this will land in Raspbian or Debian?

[kpet]

Landing clvk in Debian is definitely something that's been at the back of my mind but Debian moves slowly and whatever version we land there first will be very the only thing folks see via Debian for a long while (until the next Debian version I guess). I'm a bit wary of folks installing clvk, testing it and uninstalling it 5 mins later because they're facing issues that have been fixed upstream 2 years ago :). We're getting very close to making clvk pass the OpenCL CTS tests so maybe that's a good first target before we work on inclusion in Debian? Or maybe getting something out quickly is better? Input/feedback is very welcome here (and as are volunteers to package clvk for distributions :)).

[stolk]

Thanks. You are right. I think a more streamlined version would be to have github actions build the deb package. I see you are already using github actions? Do the resulting binaries get stored somewhere for retrieval?

This way, users can grab the binaries, because building it from source is not trivial. Especially if you build it natively on a rPi4: it takes a long time.

EDIT: Note that the build process could be faster if the build was able to use pre-installed dependencies, instead of building those too. I tried, but the submodule fetches are necessary.

[rjodinchr]

As discussed here, a release workflow could contained tests that are not run on a per commit basis. Here is a list of things that could fall into that category:

• https://github.com/kpet/clvk/issues/538
• https://github.com/kpet/clvk/issues/442
• https://github.com/kpet/clvk/issues/347
• https://github.com/kpet/clvk/issues/355

[kpet]

I agree automating the build of distro packages would be useful, I've created https://github.com/kpet/clvk/issues/546.

I see you are already using github actions? Do the resulting binaries get stored somewhere for retrieval?

Yes, they do but there does not seem to be an easy way to provide a direct link to the latest. You can click on the "Presumit passing" link at the top of the README file to navigate to the list of runs and then pick the latest build on the main branch (see https://github.com/kpet/clvk/actions/runs/5153290975 for an example). The artifacts can be downloaded from there. Having said that we don't have an ARM64 / Linux build that you could use directly on the rPi.

EDIT: Note that the build process could be faster if the build was able to use pre-installed dependencies, instead of building those too. I tried, but the submodule fetches are necessary.

This is not easy to do without having releases of clspv that align to specific LLVM releases. Maybe we could start thinking about this. It could drastically reduce the build time of clvk/clspv.

[truboxl]

Cross compiling should be easy. I have done this for Android with 4 architectures and clvk seems to be working. And this repo has done android-aarch64 too.