release: update release README.md and remove old scripts #1610
Conversation
| @@ -6,11 +6,52 @@ binaries are now reproducible, allowing developers to build the binary on | |||
| distinct machines, and end up with a byte-for-byte identical binary. However, | |||
| this wasn't _fully_ solved in `go1.13`, as the build system still includes the | |||
| directory the binary is built into the binary itself. As a result, our scripts | |||
| utilize a work around needed until `go1.13.2`. | |||
| utilize a work around needed until `go1.13.2`. | |||
There was a problem hiding this comment.
One other thing related to this, is that all the releases should note which Go version was used to build the release so people can properly reproduce the binaries if they wish.
There was a problem hiding this comment.
Should have resolved this, placed notes in both the section for maintainers and the description up top
release/README.md
Outdated
|
|
||
| Sign the `manifest-<TAG>.txt` file like so: | ||
| ```sh | ||
| gpg --output manifest-<TAG>.txt.sig --sign manifest-<TAG>.txt |
There was a problem hiding this comment.
I usually sign with a detached sig. This produces a smaller output (as the document itself isn't included in the signature). Based on your example above, signing with a detached sig would look something like:
gpg --sign --detach-sig manifest-<TAG>.txt
We can drop the --output, as it's automatically create the sig in a file name that adds .sig to the referenced file to be signed.
There was a problem hiding this comment.
Changed to detached sig, should be good now
Rjected
force-pushed
the
release_docs
branch
3 times, most recently
from
cf0eb8e
to
6278f3e
Compare
- remove prep_release.sh and notes.sample - update license in release.sh - add notes for maintainers on the release process - mention CHANGES file modifications
Should be addressed, let me know what you think! |
This should hopefully help document the steps to publish a release on the maintainer side of things, if there are any details left out or additional steps that should be documented, feedback is welcome!
Would like input from:
@jcvernaleo
@Roasbeef