<div dir="ltr"><div dir="ltr">On Fri, Oct 21, 2022 at 2:44 AM Harald Sitter <<a href="mailto:sitter@kde.org">sitter@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Servas,<br></blockquote><div><br></div><div>Hi Harald,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I've been pondering a bit what releases should look like in this brave<br>
new world we are in, with po data inside repos, and would like to<br>
propose the following:<br>
<br>
- new releaseme program; run with `--version 1.0.0 --ref master<br>
plasma-workspace`<br>
- tells invent to make a release with tag v1.0.0.0 (the terminal zero<br>
is managed by the program? through inspecting existing tags)<br>
- downloads tarball<br>
- GPG signs it<br>
- uploads all artifacts to <a href="http://download.kde.org" rel="noreferrer" target="_blank">download.kde.org</a> (with chown?) to $scope/1.0.0/<br></blockquote><div><br></div><div>Just to be sure we're all on the same page, are you talking about making use of <a href="https://docs.gitlab.com/ee/user/project/releases/">https://docs.gitlab.com/ee/user/project/releases/</a>?</div><div><br></div><div>I'm not sure it is best that we upload tags prior to making the release public, but for those independently released projects that go public immediately the workflow you are describing below should work.</div><div>By uploading all artifacts I assume you are referring to <a href="ftp://upload.kde.org">ftp://upload.kde.org</a>?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- distros package stuff. find issues<br>
- program is run again with `--version 1.0.0 --ref master<br>
plasma-workspace` to respin<br>
- same publishing dance as before but now with v1.0.0.1<br>
<br>
- release step can be repeated any number of times. always<br>
incrementing the implicit fourth version element.<br>
<br>
Obviously ref could also be a stable branch or indeed a release branch<br>
specifically for spinning the release off of e.g. think a Plasma/1.0.0<br>
branch whose sole purpose is to cherry pick into and release from -<br>
not saying we should do it that way, but it's an option.<br>
<br>
The primary complication here is that since invent releases are based<br>
on tags we'd need to tag each respin. That could actually work in our<br>
favor though. A while ago Nate proposed that we do micro patch<br>
releases instead of asking distros to package patches - that would be<br>
just like a respin in this new world order. So, e.g. at release time<br>
of Plasma 1.0.0 the actual tarball of plasma-workspace may be<br>
1.0.0.25, a critical bugfix may then land as 1.0.0.26 in that same<br>
directory a couple hours later. The only difference would be that the<br>
previous 25 respins were done while the 1.0.0 dir was private, and .26<br>
happened after it was published.<br>
<br>
Thoughts? Other complications I've not foreseen yet?<br>
<br>
HS<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>