[mosh-devel] Mosh 1.4.0 is available on GitHub

Alex Chernyakhovsky alex at achernya.com
Fri Oct 28 10:37:45 EDT 2022


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
<wolfgangesanyer at 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 <alex at 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 <keithw at 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 <bbarenblat at 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 at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/mosh-devel



More information about the mosh-devel mailing list