Release v0.8.1 #868
Release v0.8.1 #868
Conversation
There was a problem hiding this comment.
Should we update the class hashes in the codumentation in here as well?
One suggestion, I think is worth creating the release branch PR from a fork, instead of directly pushing to the repo, because the docsite is automatically updated with the latter (it currently shows 0.8.1 even when the PR hasen't been reviewed), and this could be confusing to users.
Not really, this should be done whenever we update the compiler version, as documented. I'll try to exceptionally update them in here.
this is the same reason we protected the branch. I think we should use an alternative branch, not depending on us creating the branch from a fork. I wonder whether we should change the docsite config so it pulls the tag instead of the commit branch. I think we need to think this further and I'd rather not block this release because of this. |
There was a problem hiding this comment.
Should we update the class hashes in the codumentation in here as well?
+1
One suggestion, I think is worth creating the release branch PR from a fork, instead of directly pushing to the repo, because the docsite is automatically updated with the latter (it currently shows 0.8.1 even when the PR hasen't been reviewed), and this could be confusing to users.
What about changing the sources key to tags instead of branches in playbook.yml on the docsite repo? We'd also have to change release-v* to v* in the playbook (and be mindful if we ever tag anything other than a release that it doesn't start with a v)
But in this case, we are updating the compiler version from 2.3.1 to 2.4.1, right? I know not exactly in the PR, but the last class hashes documented were using 2.3.1 when the repo is now using 2.4.1. |
|
Indeed. I was just stating that it's not the standard procedure to do it in these PRs. |
No description provided.