search

KhronosGroup / SPIRV-LLVM-Translator

A tool and a library for bi-directional translation between SPIR-V and LLVM IR
Other
479 stars 213 forks source link

Add automated release workflow #2586

Closed ZzEeKkAa closed 4 months ago

ZzEeKkAa commented 4 months ago

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

Merge process

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:

Merge process:

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 commented 4 months ago

CLA assistant check
All committers have signed the CLA.

MrSidims commented 4 months ago

%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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

list will probably become large and "unordered"

From my observation - it will be ordered semantically.

It appears that is not strictly ordered...

ZzEeKkAa commented 4 months ago

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

ZzEeKkAa commented 4 months ago

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 commented 4 months ago

@ZzEeKkAa works for me, thanks!

ZzEeKkAa commented 4 months ago

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 commented 4 months ago

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

MrSidims commented 4 months ago

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

asudarsa commented 4 months ago

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