Add release tag(s)

[eero-t]

Please add a release tag to a known good version, so that (besides my own) e.g. IGC release notes can tell against which version of vc-intrinsics it's been tested and built against.

[eero-t]

Any progress in getting a known working version of vc-intrinsics, and tagging it as such?

IGC is getting wider usage, so more people are bumping to this issue.

[tjaalton]

pretty please?

[eero-t]

I've understood there are multiple projects using vc-intrinsics, and that their releases use different commits of it, so vc-intrinsics tags could e.g. be specific to those other Intel projects, like this: "vc-intrinsics-igc-{version}"

[kv-sc]

IGC already have intrinsic hashes in releases:

https://github.com/intel/intel-graphics-compiler/releases/tag/igc-1.0.10183

You may see: d3cef33

The same for SPIRV-Translator.
The same for opencl-clang

There is no magic with tags. Hash is a tag. Please explain why do you need this?

[eero-t]

Referring to hashes gives an impression that the whole stack is constantly in broken state, and its testing cannot be trusted enough to guarantee (release) working versions.

vc-intrinsics considerations

Because IGC depends on opencl-clang, SPIRV-Translator and this project, it looks suspicious if they recommend different hashes of each other.

Is user (package maintainer) supposed to do detective work in finding:

• Which version is actually newest
• Which one should be used to build the whole stack, or
• Does he really need to provide multiple different versions of it? [1]

These are kind of questions that the release numbers and notes should answer to.

[1] If multiple version are really needed, package maintainer needs to support parallel installs of different versions of same package. Then there's the question that do those projects really find the correct version of vc-intrinsics?

General considerations

Distros package dependencies separately, especially ones that are (already, or likely to be) used by multiple components. They do not want components to be bundled.

There are few reasons for this:

• Smaller disk and memory footprint (both on user machines and mirrors)
• Security updates and bug fixes require updating only single package, not re-building unknown amount of other packages
• Potential legal issues (project has code from projects with different licenses, which all licenses apply to built & distributed binaries?)

Package dependencies are versioned. But version numbers that are hashes, are useless. Nobody (users etc) knows which of the versions of is newer (e.g. one containing important security or bug fix), without doing detective work in corresponding git repositories, so some external version number needs to invented for them.

Tags and releases could be taken as a kind of a promise that given version has passed at least some kind of additional verification of workings compared to other commits. Often releases include also some note of what is guaranteed / tested.

Distros have also automation for notifying package maintainers when upstream tags new release.

Considering all of above, lack of tags / releases looks unprofessional, e.g. when package maintainer needs to "sell" addition of a new component in the distro package review. What excuses he should be doing for a project that is not yet mature enough to have even its first release?

Summary

It would be good for this project to mature (get enough independence) that it has its own releases, to which the other projects refer.

[kv-sc]

Tags and releases could be taken as a kind of a promise that given version has passed at least some kind of additional verification of workings compared to other commits.

After discussion inside team we found this argument convincing. We will start semantic versioning in format major.minor.patch

Any major change will signify that we added or removed something or changed signature
Minor change we added something changing interface backward compatible (like adding value to existing enum)
Patch if we changed something that don't affect (like fixed SPIRV adaptors)

First tag will be 0.1.0, I will add it this week.

[eero-t]

Great, thanks!

Can you say anything about whether the whole compute stack release notes are (eventually) going to refer to released versions of their dependencies (instead of the current practice of referring just to "random" hashes)?

This would imply either that:

• if currently there is no working release available of some dependency, that component is encouraged to do a usable (well tested) release ASAP, so that it does not block upper level component releases,
• latest of everything is tested together until tests in all components pass, and everything is then tagged at the same time (instead of dependencies being released first),
• Or some mix of above, depending on how independent the components are at given time

[eero-t]

First tag (v0.1.0) is there now, so closing this.

Release notes about which versions of the projects using it are compatible with it would be nice too, even if it would state just something like "Compatible with latest releases of X, Y, Z at the time of the release".

PS. @tjaalton Maybe you could update the intel-vc-intrinsics packages in Debian / Ubuntu now that "vc-intrinsics" has its first tag?

[tjaalton]

thanks for the release, uploaded 0.1.0-1 to debian now