search

freedomofpress / securedrop-builder

Packaging logic for building SecureDrop-related Debian packages
GNU General Public License v3.0
7 stars 11 forks source link

Use per-component tags instead of one overall repository tag #448

Closed legoktm closed 1 week ago

legoktm commented 1 year ago

Currently when doing a new component release, we tag a new version of securedrop-builder as a whole. For example, https://github.com/freedomofpress/securedrop-builder/releases/tag/0.4.1 was for securedrop-keyring 0.1.7.

It gets confusing when in the build logs, you're verifying the 0.4.1 builder tag for the 0.1.7 keyring release. And introducing a totally different version number is just another unnecessary thing.

Instead I propose we have component tags, e.g. securedrop-keyring-0.1.7. If we're releasing multiple components at once, we could create multiple tags pointing at the same commit.

This is a relatively common thing in the Rust world where repos often have multiple components, e.g. https://github.com/tokio-rs/tokio/tags

rocodes commented 1 year ago

This would make a lot more sense. If people are okay with this change, we can start with #443 , which would be securedrop-keyring-0.2.0, and I can update the release docs.

rocodes commented 1 year ago

(Thumbsup from @zenmonkeykstop is good enough for me - proceeding :))

rocodes commented 1 year ago

I think we will also have to make a change to the packaging script, because it's not expecting the securedrop-<component>-<major>.<minor>.<patch>-rcN format.

To build securedrop-keyring, I checked out the correct tag and used the PKG_PATH method.

legoktm commented 1 year ago

I think the packaging script change will need to wait for the Python rewrite first... #436

legoktm commented 1 week ago

There are no longer individual component releases, so this doesn't matter anymore.