Redesign the release process with Delegates in mind.

[lgarron]

Now that we have a UI to generate scrambles for specific competitions, I'd like to propose that we start doing the following:

• Set a date X after which all competition must switch to TNoodle version V
• At least two weeks before X (if possible), build and release version Y.
• Update https://www.worldcubeassociation.org/api/v0/scramble-program to specify that competitions taking place on or after X must use version Y.

This way:

• It's unambiguous which version of TNoodle a given competition should be using.
• A Delegate that tries to generate scrambles a week ahead of a competition will be warned that they are using the wrong version rather than having to wait until the Monday before the competition to be sure.

For Regulations update, we can even target much father into the future. We could even specify that a new version of TNoodle will be released on e.g. Jan. 1 before the version is ready.

[campos20]

I wonder if we could use GitHub Actions for that. Also, I did not incude any technical detail on the website post since this is not useful to the regular reader (although we have details on the release here), but #419 was a valid question from someone that was paying close attention.

[lgarron]

I wonder if we could use GitHub Actions for that.

In order to take the release steps automatically? It could work, although I think I would rather focus on making these steps as easy as possible for humans to initiate (e.g. automatically archiving the TNoodle binary and updating links).

[gregorbg]

In your original issue you use "version V" and "version Y", I'd assume you meant to write "V" for both. Can you please fix this?

[gregorbg]

Also, as I understand it this boils down to "determine a fair X" and then build TNoodle accordingly. Shouldn't this be more of a Regulations-related issue?

[jfly]

I definitely like the idea of storing a history of "what versions of tnoodle were official when". Designed correctly I think that would even allow for scheduling changes in the future, rather than having to coordinate by carefully merging and deploying PRs at exactly the right time (as @lgarron said). While that specific change is actually a change to the wca website, it may have to carefully be coordinated with a change to tnoodle (of we change the api, then tnoodle needs to know about it, plus we need to make sure that old versions of tnoodle behave nicely).

[ligio90]

my ideas for this:

1. when the tnoodle version has a defined expiry date then along the text about the version it was generated with write something along the lines of "These scrambles may not be used at official WCA competitions after Date x" on the scramble sheets
2. when the tnoodle version is expired then write something along the lines of "These scrambles may not be used at any WCA competitions" on the scramble sheets also do everything lucas mentioned.