Provide releases #56
Comments
|
I've re-opened #11 - it was wrongly closed automatically due to a commit message with a "Closes #" statement that referenced an unrelated GitLab issue number. I've brought this up in the past, but we really need to stop putting these sorts of things in commit messages to avoid this sort of issue, otherwise this will keep happening. Agree that a date-based tagging scheme is best since we essentially have a rolling-release process. Releasing at most once per month seems like a sensible frequency. |
|
As agreed on the OpenCL Working Group call 2020/01/07, the headers will use a date-based versioning (YYYY-MM-DD). |
They are currently installed by app-eselect/eselect-opencl. The new package installs them exactly as app-eselect/eselect-opencl did. This also enables to better track the license; eselect-opencl currently declares GPL-2 but the headers that it installs are actually licensed under Khronos-CLHPP. Upstream is moving to a date-based versioning scheme (see KhronosGroup/OpenCL-Headers#56) so I've made up a first version for the current state using that scheme. Since the work to integrate the headers into Gentoo was done, upstream has moved to Github and the per-OpenCL-version headers have been superseded by so-called unified headers that work for all versions of OpenCL. I am going to be creating the first upstream release soon and would like to migrate Gentoo to the unified headers if people are happy with this (in practice the headers are hard-coded to 1.2 currently). I also intend to tackle the C++ bindings next if people are happy with the direction. eselect-opencl bundles an old version but there is already a more recent clhpp package (and an upcoming release). Signed-off-by: Kévin Petit <kpet@free.fr>
They are currently installed by app-eselect/eselect-opencl. The new package installs them exactly as app-eselect/eselect-opencl did. This also enables to better track the license; eselect-opencl currently declares GPL-2 but the headers that it installs are actually licensed under Khronos-CLHPP. Upstream is moving to a date-based versioning scheme (see KhronosGroup/OpenCL-Headers#56) so I've made up a first version for the current state using that scheme. Since the work to integrate the headers into Gentoo was done, upstream has moved to Github and the per-OpenCL-version headers have been superseded by so-called unified headers that work for all versions of OpenCL. I am going to be creating the first upstream release soon and would like to migrate Gentoo to the unified headers if people are happy with this (in practice the headers are hard-coded to 1.2 currently). I also intend to tackle the C++ bindings next if people are happy with the direction. eselect-opencl bundles an old version but there is already a more recent clhpp package (and an upcoming release). Signed-off-by: Kévin Petit <kpet@free.fr>
If it would be date version patter please use YYYY.MM.DD as using |
|
I've now made the first release, using dots as separators as suggested by @kloczek. I'll close this. If anyone needs a release before we make another one, please create an issue. |
|
/me is bowing Thank you :) |
We're not currently providing releases of the headers. This makes a number of things like integrating them into Linux distributions a bit challenging. It seems we got a request in the past that was closed without replying or providing a solution (#11). (cc @ghisvail, @vdanjean).
I suggest we use a date-based tagging scheme (e.g. YYYY-MM) to avoid the confusion with OpenCL versions.
The text was updated successfully, but these errors were encountered: