Some points of ambiguity came up in the securedrop-client 0.9.0 release process:
the application version should be updated to the next release version only, not to successive RCs (release candidate versions are tagged and the packages generated via the changelog and build script in securedrop-builder)
similarly, the RC versions recorded in the package's debian changelog under securedrop-builder should not be merged back to securedrop-builder's main branch, it should only ever have release versions.
version format should be Debian-native (this is being handled by updates to the scripts to validate input)
in general, some ritual stuff around roles/responsibilities and expected communication touchpoints should be documented.
Some points of ambiguity came up in the securedrop-client 0.9.0 release process:
mainbranch, it should only ever have release versions.Docs should be updated to reflect the above.