Keith: I think you can sign the tag and push it directly. I had to push the mosh-1.4.0 tag directly myself.
Wolfgang: I think that we need to write up a RELEASING.md so (well, I) don't forget about these steps. Do you have the cycles to write up a quick document with the procedure? Things I can think of right now: Procedure: Make a tag 1. Update configure.ac with the new version 2. Push an annotated git tag (the -a argument) [ CI will enforce that the tag in configure.ac and the git tag match ] Procedure: Release 1. Upload a release-candidate tag 2. Send announce email, asking for testing 3. Upload to Debian experimental, perform Fedora scratch-builds for all supported releases, check Ubuntu auto-build PPA 4. [ Wait for reports to trickle in ] 5. Update ChangeLog 6. Upload a release tag 7. Update website 8. Send announce email Does that look right? Anything I'm missing? Sincerely, -Alex On Fri, Oct 28, 2022 at 7:14 AM Wolfgang E. Sanyer <wolfgangesan...@gmail.com> wrote: > > My opinion (fwiw): i agree with Alex that the tag shouldn't be unpushed. Last > time this happened caused some headaches for me personally so maybe I'm > biased 😅 > > I'd hold off on revving for the changelog too: Alex and I have chatted a bit > and I think we'd both like to get this project to a point where the release > process is more streamlined, and easier to accomplish on a more regular > cadence. So, maybe this changelog thing can provide some motivation to get to > that 1.4.1 release > > El jue, 27 de oct de 2022, 11:23 p. m., Alex Chernyakhovsky > <a...@achernya.com> escribió: >> >> I don't think we should un-push the tag. I also don't think it's worth >> rev'ing the version over the changelog? But I'd definitely rev the version >> if we think we need to include it. >> >> Sincerely, >> -Alex >> >> On Thu, Oct 27, 2022, 10:42 PM Keith Winstein <kei...@cs.stanford.edu> wrote: >>> >>> Thanks Ben. I didn't realize we had pushed an unsigned tag already. I >>> guess... my tentative thought would be let's un-push the "mosh-1.4.0" tag >>> since I'd rather maintain past practice and have that be a signed tag >>> anyway. Unless you think this will cause lots of problems (but I don't >>> think it will). I don't think we need to rev the version number unless you >>> do. >>> >>> And then I think sure, please do what you think is right with the ChangeLog >>> and the debian/changelog however you prefer, and then I can tag and sign >>> that and we can cut the source tarball from there. Sorry for the >>> last-minute friction here. >>> >>> -Keith >>> >>> On Thu, Oct 27, 2022 at 7:14 PM Benjamin Barenblat <bbarenb...@gmail.com> >>> wrote: >>>> >>>> On Wednesday, October 26, 2022, at 8:33 PM -0700, Keith Winstein wrote: >>>> > (1) Should we update the ChangeLog file for the source release? It looks >>>> > like you (and achin?) already wrote text for it. >>>> >>>> I completely forgot about the changelog. Yes, we should update that. >>>> What do you think – should we update the changelog and push a 1.4.1 tag, >>>> or should we update the changelog and replace the existing 1.4.0 tag >>>> with a new one that includes the changelog update? >>>> >>>> > (2) Should I make the final 1.4.0 debian/changelog entry (probably >>>> > including the same bullet points as we'll put into ChangeLog) or do you >>>> > want to make a PR for that? >>>> >>>> I can take care of the Debian work. Debian generally prefers to keep >>>> upstream changelog entries out of debian/changelog – debian/changelog is >>>> supposed to be a changelog for the packaging, not the package. But I’ll >>>> make sure the Mosh changelog is included in /usr/share/doc/mosh. >>>> >>>> > (3) In the past the release announcement email named/credited the >>>> > "primary >>>> > developer and release manager" -- what do you want it to say this time? >>>> > (I.e who should be credited and in what order?) >>>> >>>> For developers, it looks like cgull, Anders, Alex, and I all contributed >>>> over 100 lines of diff to Mosh since the last release. It’s an arbitrary >>>> cutoff, but it seems as good as any to me. I think cgull should probably >>>> go first on the list, since they were making active contributions until >>>> 2021. >>>> >>>> As for release manager, I think that’s Alex. He was definitely the >>>> forcing function here. :) >> >> _______________________________________________ >> mosh-devel mailing list >> mosh-devel@mit.edu >> https://mailman.mit.edu/mailman/listinfo/mosh-devel _______________________________________________ mosh-devel mailing list mosh-devel@mit.edu https://mailman.mit.edu/mailman/listinfo/mosh-devel