Point CI back to liboqs main

[SWilson4]

To hopefully save @baentsch some time making the oqs-provider release tomorrow 😁

[baentsch]

Two nits.

[baentsch]

Much appreciated, @SWilson4 ! RC1 done. Will mark as final tomorrow if not hearing protests -- shouldn't happen, given the contents had been reviewed before...

Edit/Add: Could you please also update the Wiki documenting how the release process should work as per your recommendation?

[SWilson4]

Edit/Add: Could you please also update the Wiki documenting how the release process should work as per your recommendation?

Done. I added a "release candidate" step and clarified a couple of permissions-related points. Please feel free to iterate on it if you find an ambiguity.

I also changed the base branch of this PR to main now that the RC has been merged in.

Updates made

[baentsch]

I added a "release candidate" step and clarified a couple of permissions-related points. Please feel free to iterate on it if you find an ambiguity.

Thanks! But I still don't quite understand how to proceed from RC to final release though: Do I get it right that I'd now have to wait for an OQS meeting to confirm the RC is OK? What about having concrete acceptance criteria or remote approvals by someone allowing this to be faster? Who would this be? I'm the sole maintainer but have been stripped of the github admin rights required to proceed as per the Wiki.

Anyway, after this RC approval, would I then

• have to create a new PR removing the "-rc" monikers from the corresponding files (at least RELEASE.md)?
• get that PR approved
• merge the PR
• create final release
  ?

This sounds pretty complicated: I must be missing something. Was it incorrect for me to merge the 061rc1 branch to main and do the RC on that commit? Was it incorrect to have rc monikers in any file? Or should I have created the RC1 on this branch (not yet merging to main), waiting for it to be approved somehow, then fix it up to be final (remove rc monikers) and only then merge-and-release? Do you have a write-up somewhere how liboqs "main" branch releases are done so that I can learn from that? I only know about this and it's also silent about these steps.

[SWilson4]

Thanks! But I still don't quite understand how to proceed from RC to final release though: Do I get it right that I'd now have to wait for an OQS meeting to confirm the RC is OK? What about having concrete acceptance criteria or remote approvals by someone allowing this to be faster? Who would this be? I'm the sole maintainer but have been stripped of the github admin rights required to proceed as per the Wiki.

I'll admit that I was deliberately ambiguous on that point, as I don't believe there are concrete acceptance criteria currently. (And I'd prefer not to come up with them on my own and codify them as a "benevolent dictator." 😜)

Anyway, after this RC approval, would I then

* have to create a new PR removing the "-rc" monikers from the corresponding files (at least RELEASE.md)?

* get that PR approved

* merge the PR

* create final release
  ?

This sounds pretty complicated: I must be missing something. Was it incorrect for me to merge the 061rc1 branch to main and do the RC on that commit? Was it incorrect to have rc monikers in any file? Or should I have created the RC1 on this branch (not yet merging to main), waiting for it to be approved somehow, then fix it up to be final (remove rc monikers) and only then merge-and-release? Do you have a write-up somewhere how liboqs "main" branch releases are done so that I can learn from that? I only know about this and it's also silent about these steps.

That seemed to me be the quickest and easiest way to get the "-rc" suffixes out of the necessary files without pushing directly to main. Perhaps it is not ideal for future releases, but for this one I think it's the best way forward.

I don't think there's a standardized procedure for liboqs releases from main either... At least, it was done differently for 0.9.0 and 0.10.0. For 0.9.0 former, the release candidate PR was merged into main, and then the final release was committed directly to main (just removing -rc1 from everything). For 0.10.0, I believe that the release candidate branch was not merged until the -rc suffixes had been removed.

My preference for future releases from main would be to work on an rc branch which is only merged into main after it's been approved (both by PR approvals and whatever hypothetical criteria) and had the -rc* versioning suffixes removed. The final release tag would correspond to the merge commit. This means that there is only one PR and no direct commits to main required. What do you think of this approach? I can take a stab at editing the wiki(s) to codify the process.

Sorry for any confusion I've caused with the wiki edits; I really am trying to streamline things as much as I can without overstepping.

[baentsch]

concrete acceptance criteria

Yours Truly considers a working nginx integration test as the (currently absolutely acceptable) minimum for this. Kindly done by @bhess in open-quantum-safe/oqs-demos#272

a "benevolent dictator."

Would be more welcome than a malevolent, non-contributing dictator just making life miserable.

That seemed to me be the quickest and easiest way to get the "-rc" suffixes out of the necessary files without pushing directly to main

Now done in #434. I'll merge when approved, do final release afterwards and then merge this PR to get back to dev mode (see separate Approval comment).

[baentsch]

LGTM. Even better would be an update to the version info (to 0.6.2-dev) in CMakeLists.txt.

[baentsch]

LGTM. Even better would be an update to the version info (to 0.6.2-dev) in CMakeLists.txt.

Tagging @SWilson4 : Please change the version ID and merge as you find time to close out this release cycle. Thanks in advance.