Add automated release workflow

[ZzEeKkAa]

Some of the upstream PRs are getting backported to the llvm_release_* branches, but those changes are never released. That prevents them from distributing as precompiled packages in various distributions like conda-forge and others. This PR targets this issue by creating automated workflow that is triggered once a month and generates automated releases for each such branch if there were changes since last release.

This PR

• Adds workflow to generate releases every month from llvm_release_* branches in the format %llvm_major%.%llvm_minor%.%latest patch version +1%. For example:
  • v18.1.1
  • v17.0.2
  • v17.0.1
  • v14.0.1
  • etc
• Release description matches as close as possible to current releases. The only difference is that llvm versions is represented by two numbers, instead of three, because it is impossible to recover exact version. You can check out example of generated versions here (there are few releases from the original proposal): https://github.com/ZzEeKkAa/SPIRV-LLVM-Translator/releases
• Workflow is set to be triggered once a month. It is also possible to trigger it manually from github actions UI.

Merge process

• Merge the PR to main
• Trigger workflow manually

Note

There is no need to backport changes to all branches, since workflow dispatch on schedule basis can be performed only from main branch.

Original proposal

I want to create this PR as a DRAFT and initial discussion about automated release. So I would like to hear feedback before merging the PR.

This PR:

• Adds workflow to generate releases on every push to llvm_release_* branches in the format %llvm_version%.%commits since tag%. For example:
  • v18.1.0.14
  • v17.0.0.29
  • v17.0.0.28
  • v14.0.0.196
  • etc
• Release description matches as close as possible to current releases. You can check out example of generated versions here: https://github.com/ZzEeKkAa/SPIRV-LLVM-Translator/releases

Merge process:

• Merge the PR to main
• Backport the PR to all llvm_release_* branches

Open questions:

1. How often should we do releases? On every push, weekly, bi-weekly, monthly, quarterly?
2. Are we okay with proposed version system?
3. [Kind of out of scope] Do we need to tag minor releases of llvm (like '14.0.6', etc)
4. Is release description is okay?

Fixes: #1898
Fixes: #1508

[CLAassistant]

All committers have signed the CLA.

[MrSidims]

%llvm_version%.%commits since tag%

I'm slightly leaning towards setting the date of the release as it's easier to interpret by the one who reads it, but I'm not sure if it's an industry standard. But if we decide to release on every push, then I'd prefer to have number of commits encoded.

How often should we do releases? On every push, weekly, bi-weekly, monthly, quarterly?

It feels like if we go with %commits since tag%, then releasing every push should be the way to go. Otherwise something like monthly releases looks good to me. @aratajew as IGC relies on the translator it might impact you. What would be your preference?

Is release description is okay?

IMHO automatically generated changelog is OK

[Kind of out of scope] Do we need to tag minor releases of llvm (like '14.0.6', etc)

It's a good question. Such tags imho should be created manually, this automation should use the latest among them to create new patch/timestamp tags.

[svenvh]

Thanks for putting up a proposal!

• How often should we do releases? On every push, weekly, bi-weekly, monthly, quarterly?

In #1898 it seems the proposal was monthly. That sounds good to me as a start, if we want more (or less) frequent releases we can always tune the interval later.

• Are we okay with proposed version system?

Perhaps it would be best to follow semantic versioning, so we'd need to change the format slightly to comply. Or we could follow a different non-standard format to include the year+month.

• [Kind of out of scope] Do we need to tag minor releases of llvm (like '14.0.6', etc)

We're not really following the patch releases of llvm since all 14.0.x releases should be compatible. For releases that break compatibility, we may need to decide when it happens perhaps?

• Is release description is okay?

Following what we have done for current releases sounds good to me.

[svenvh]

It feels like if we go with %commits since tag%, then releasing every push should be the way to go.

I think this would give a lot of "tag/release pollution", so I'd advise against that.

[ZzEeKkAa]

Thank you for the feedback! I love the idea to follow sem version specification, but package relies on llvm versioning. Should we then keep only major version and keep two others in sync with specification, or should we keep major and minor in sync with llvm and update only the third part on our own. Speaking of, should not llvm_release_180 be llvm_release_181?

Since these are automated release, keeping updated one number should be easier than updating two. So it should be something either 14.0.<automated> or 14.0.6.<automated>.

I think this would give a lot of "tag/release pollution", so I'd advise against that.

What is the drawback? It seems like backport releases are not that frequent. since 14'th release there is less than 200 commits. What should we do if there are no updates since last release (e.g. a moth). Do clients what to have backports imminently on commit merge? Should we add option to manually release if such thing is critical? How would it fit into versioning?

[svenvh]

or should we keep major and minor in sync with llvm and update only the third part on our own.

Practically speaking this might be the easiest, because in this project itself we haven't really differentiated between minor and patch versions until now. So aligning major and minor to llvm seems reasonable. We should probably document that, maybe you can add a section to README.md too?

Speaking of, should not llvm_release_180 be llvm_release_181?

Good point, or even llvm_release_18.x following llvm's convention. Not sure if we should rename the current active branch, but we should keep this in mind when branching for llvm 19.

I think this would give a lot of "tag/release pollution", so I'd advise against that.

What is the drawback?

One concern is that it makes https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases harder to navigate. Right now it's an ordered list with the newest release on top. If we make an automatic release for every backport, the list will probably become large and "unordered" (it will reflect the order of branches getting a commit I suppose, which isn't very useful and might confuse folks).

What should we do if there are no updates since last release (e.g. a moth)

Don't create a new release in that case I'd say, as it doesn't add any value.

Should we add option to manually release if such thing is critical? How would it fit into versioning?

Manual releases should always remain an option. For versioning, any new release could follow a 18.1.(latest + 1) approach so there is no chance of versioning conflicts with a manual release.

[ZzEeKkAa]

list will probably become large and "unordered"

From my observation - it will be ordered semantically. The PR is made to apply latest tag only for most recent major release.

Summarizing everything, thing to be updated:

1. Release every month. If there are no updates since last release - do nothing.
2. Version system will be <(MAJOR LLVM).(MINOR LLVM).(latest + 1)>.

@svenvh who should approve this design so I can get the PR updated and ready to merge? And what are the next steps?

[svenvh]

@svenvh who should approve this design so I can get the PR updated and ready to merge? And what are the next steps?

Your plan sounds good to me. If @MrSidims also agrees you can start updating the PR. Not sure if anyone else from Intel has an opinion?

[MrSidims]

I'm fine with the schema, thanks for working on this! I'd like to also hear from @kurapov-peter as he is a potential customer of the feature.

[ZzEeKkAa]

Thank you @svenvh , @MrSidims ! I'll try to update the PR till the EOW. Should we wait for @aratajew ?

And something I've been thinking in terms of usability. Are all those backports ever introduce breaking compatibility? I'm thinking of other project using it through dynamic linking, could they pin project in the way version>=14.0.2;<15.0.0a0 for example?

[kurapov-peter]

I'm fine with the schema, thanks for working on this! I'd like to also hear from @kurapov-peter as he is a potential customer of the feature.

No preference as long as it's clear what's latest (and now it is)

[asudarsa]

This looks great and I read through the conversation thus far and it sounds like a nice addition. Will we be adding a README file on how to consume these packages or is that expected to be a known method?

thanks @ZzEeKkAa for adding this..

[ZzEeKkAa]

Thank you everybody! This PR is now ready to go. Just one open question that can be addressed in future releases (in other words, can we guarantee semantic versioning compatibility):

Are all those backports ever introduce breaking compatibility? I'm thinking of other project using it through dynamic linking, could they pin project in the way version>=14.0.2;<15.0.0a0 for example?

[ZzEeKkAa]

Will we be adding a README file on how to consume these packages or is that expected to be a known method?

I guess it is known method so far...

[ZzEeKkAa]

list will probably become large and "unordered"

From my observation - it will be ordered semantically.

It appears that is not strictly ordered...

[ZzEeKkAa]

@MrSidims @svenvh could you take a look and review/merge changes?

[asudarsa]

LGTM. Thanks

[MrSidims]

LGTM, thanks!

Can be done in a separate PR: IMHO it's a good idea to move a little bit groomed PR description into a separate doc placed here https://github.com/KhronosGroup/SPIRV-LLVM-Translator/tree/main/docs

@svenvh are you OK to merge this?

[svenvh]

Just one nit; it would indeed be nice to have some documentation too (adding to README.md?).

[ZzEeKkAa]

I've fixed comments and added brief description about automated releases in README. @MrSidims @svenvh does it meets what you had in mind for the doc or more detailed documentation needed to add to ./doc before merging the PR?

[MrSidims]

@ZzEeKkAa works for me, thanks!

[svenvh]

Thanks for the doc update!

[ZzEeKkAa]

Thank you for reviews and merging it!

Could you please go Actions -> Automated releases and trigger the workflow so that we get initial releases without waiting next month?

[MrSidims]

Sure! Lets see how it goes https://github.com/KhronosGroup/SPIRV-LLVM-Translator/actions/runs/9386710465

[MrSidims]

And it works, https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases/tag/v18.1.1! @ZzEeKkAa thanks a lot for your contribution!

[asudarsa]

Nice job @ZzEeKkAa and @MrSidims . This will be very useful. Thanks