releases driven through invent?

[Harald Sitter]

Servas,

I've been pondering a bit what releases should look like in this brave
new world we are in, with po data inside repos, and would like to
propose the following:

- new releaseme program; run with `--version 1.0.0 --ref master
plasma-workspace`
- tells invent to make a release with tag v1.0.0.0 (the terminal zero
is managed by the program? through inspecting existing tags)
- downloads tarball
- GPG signs it
- uploads all artifacts to download.kde.org (with chown?) to $scope/1.0.0/

- distros package stuff. find issues
- program is run again with `--version 1.0.0 --ref master
plasma-workspace` to respin
- same publishing dance as before but now with v1.0.0.1

- release step can be repeated any number of times. always
incrementing the implicit fourth version element.

Obviously ref could also be a stable branch or indeed a release branch
specifically for spinning the release off of e.g. think a Plasma/1.0.0
branch whose sole purpose is to cherry pick into and release from -
not saying we should do it that way, but it's an option.

The primary complication here is that since invent releases are based
on tags we'd need to tag each respin. That could actually work in our
favor though. A while ago Nate proposed that we do micro patch
releases instead of asking distros to package patches - that would be
just like a respin in this new world order. So, e.g. at release time
of Plasma 1.0.0 the actual tarball of plasma-workspace may be
1.0.0.25, a critical bugfix may then land as 1.0.0.26 in that same
directory a couple hours later. The only difference would be that the
previous 25 respins were done while the 1.0.0 dir was private, and .26
happened after it was published.

Thoughts? Other complications I've not foreseen yet?

HS