Prerelease checklist #16244
Prerelease checklist #16244
Conversation
| - [ ] Mention it on [Twitter](https://twitter.com/solidity_lang). | ||
| - [ ] Mention it on [Fosstodon](https://fosstodon.org/@solidity/). | ||
| - [ ] Mention it on [`#solidity` channel on Matrix](https://matrix.to/#/#ethereum_solidity:gitter.im). | ||
| - [ ] Mention it on [`#solc-tooling`](https://matrix.to/#/#solc-tooling:matrix.org). |
There was a problem hiding this comment.
I'm a undecided about this bit. On one hand, we want prereleases to be super light, so comms should be optional. On the other hand not telling anyone defeats the point, so we should mention it somewhere.
I think what we want it to only advertise as much as needed to reach the people who we expect feedback from.
There was a problem hiding this comment.
What would be the typical delay between a prerelease and a full release?
There was a problem hiding this comment.
I think a week at the minimum. Not much point doing one when we have a full release just around the corner.
Hard to say what the maximum would be. They won't be regular so it can be anything.
| - [ ] Take the `github-binaries.tar` tarball from `c_release_binaries` run of the tagged commit on Circle CI and add all binaries from it to the release page. | ||
| Make sure it contains four binaries: `solc-windows.exe`, `solc-macos`, `solc-static-linux` and `soljson.js`. |
There was a problem hiding this comment.
Should we also include the source tarball in a prerelease?
There was a problem hiding this comment.
Yeah, let's. The github archives don't contain the submodule sources so otherwise we have an incomplete set of sources to build it as reference.
There was a problem hiding this comment.
Well, ok, though I'm not sure we'd ever really want to build it as a reference. The whole point of a prerelease are the binaries. We don't prepare a source archive for nightlies either.
cameel
force-pushed
the
prerelease-checklist
branch
3 times, most recently
from
a3390bc to
a540037
Compare
| - [ ] Mention it on [Twitter](https://twitter.com/solidity_lang). | ||
| - [ ] Mention it on [Fosstodon](https://fosstodon.org/@solidity/). | ||
| - [ ] Mention it on [`#solidity` channel on Matrix](https://matrix.to/#/#ethereum_solidity:gitter.im). | ||
| - [ ] Mention it on [`#solc-tooling`](https://matrix.to/#/#solc-tooling:matrix.org). |
There was a problem hiding this comment.
What would be the typical delay between a prerelease and a full release?
| - [ ] Bump vendored dependencies. | ||
| - [ ] Lean back, wait for bug reports and repeat from step 1 :). | ||
|
|
||
| ## Prerelease |
There was a problem hiding this comment.
Should this section be moved up to be before ## Full release? Also, when creating a checklist prior to a (pre)release, is only the relevant section copied to hackmd/notes? E.g. if we're doing a full release, do we just copy the ## Full release section?
There was a problem hiding this comment.
Should this section be moved up to be before
## Full release?
I think it fits better at the end. The release is the main thing, requirements are based primarily on it, etc. The prerelease checklist is also more concise because the assumption is that you read the release checklist first - this would not work the other way around.
Also, when creating a checklist prior to a (pre)release, is only the relevant section copied to hackmd/notes? E.g. if we're doing a full release, do we just copy the
## Full release section?
Yeah, not much point including the requirements. They are something to be checked beforehand, not during the release.
| - Click the `Publish release` button on the release page, creating the tag. | ||
| - [ ] Wait for the CI runs on the tag itself. | ||
| - [ ] Switch to the tag that archives have to be created for. | ||
| - [ ] Create the `prerelease.txt` file: `scripts/prerelease_suffix.sh pre "$(git describe --tags --exact-match)" > prerelease.txt`. |
There was a problem hiding this comment.
Note that this script is a part of #16246.
cameel
force-pushed
the
prerelease-checklist
branch
from
a540037 to
b02d176
Compare
4 participants
Part of #16123.
This PR adds a separate checklist for optional pre-releases as a part of our new process for experimental features.