We're writing a release guide for a new Cargo project. Looking forward to experienced sharing your knowledge and reviewing the items especially where can be improved if any.
A brief intro of the project: Engula is a serverless storage engine which can serve different workload adaptively; for example, we're currently working on a distributed KV engine with transaction and index support.
Kudos! It's great that you folks have established release guide documentation. Provided that it remains up-to-date, and that you demonstrate its correctness by having multiple community members serve as release manager, it guards the project against developing excessively tricky release procedures, or relying on single-bus-factor devs who are the only ones who know all the release steps.
I didn't spot anything obviously problematic about how you're handling git tagging, the scheduling aspects, etc. There may be slightly different ways of doing things out there, but it looked to me like what you've documented all falls within common practice.
I suppose one item of interest is how you decide what gets released:
When the current release is almost ready, we can start a release process. First of all, decide on a time, T, to do the release.
As the number of stakeholders in a community grows, just what gets released can become contentious — for example if some feature which doesn't have consensus support gets rushed out in a release, or if some change gets released which breaks back compat in a way which some community members consider meaningful but others don't. I don't know how soon you might encounter this issue, though.
Also, it was interesting to me that I did not see anything about creating and uploading cryptographic signatures or checksums. I used to be an expert on the release process at the Apache Software Foundation (I led a redrafting effort of the official ASF Release Policy in 2015) where such things are required. However I have yet to immerse myself in publishing on crates.io, so today I started taking a look around...
It seems that the crate metadata includes a SHA256 checksum which is presumably generated automatically on upload. I guess that means it's handled for you! And in a way which should be impossible to screw up under ordinary circumstances.
Unfortunately checksums are easier to spoof than public-key signatures (the downstream user is depending on the single-sourced index metadata being correct, rather than on diverse public keys that they've decided to trust). I wish that there was a standard way for individuals to attest that a release is genuine beyond having been logged in when it was published to crates.io (via PGP signatures, or something similar but with fewer issues — ideally, "quorum publishing" where a release isn't official until a "quorum" of identities attest to it via cryptographic signatures). Work on this front is ongoing1, 2, though — and in the absence of official guidance my take would be to simply stay aware and to participate once a system comes on line. If your project is mature enough to have documented a release process, you're the target audience.
Finally, I note that although you've called it a "release policy" in this users.rust-lang.org post, the actual document is called a "Release Guide" — and "Guide" definitely what you want. It's not written like a policy, with strict clauses meant to be followed explicitly. And as someone who has spent way too much time arguing over what is enforceable and what is not: policies are something to be avoided unless absolutely necessary.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.