Last stable release was in July. There have been some useful features added to mosh, like --predict-overwrite and true color. Maybe its time to cut a RC in the hopes of moving towards a new stable release?
nthapaliya
All 24 comments
users of browsh could avoid compiling from source for true color support
untoreh
on 31 Jul 2018
Please do!
https://en.wikipedia.org/wiki/Release_early,_release_often
vvug
on 12 Sep 2018
@cgull the next Debian transition freeze will be on 2019-01-12. It is probably time to cut a release if you want a newer version of mosh to be in Debian buster. Especially if you plan to release one or two release candidates...
vvug
on 18 Sep 2018
Hey @cgull , it'd be great to have a new release :)
si14
on 4 Jan 2019
I find it is often helpful to nominate and publish a release team for the next, N+1 release, then let a release-manager and/or that team nominate a target date and release milestones/goals/blockers. Just an idea. And recognising that everyone of course is a volunteer.
javabrett
on 13 Feb 2019
A release or RC would be great at this point. I think there are a lot of people that are looking for true color support without resorting to building from source.
ghost
on 8 Mar 2019
Author of Browsh here, I know the pain of keeping people up to date. So in sympathy I offer the suggestion: Perhaps at least a roadmap or some rationale for the next release or lack thereof?
tombh
on 10 Mar 2019
Seconding this, I get a bit nervous when it's been 2 years since the last release, especially for something involving remote code execution!
liamdawson
on 2 Apr 2019
@cgull and I should make a plan for a new release and figure out who is going to do the work (since I know a lot of people want 24-bit colors and other features that are only in Git), but this last comment is so confusing to me. Mosh has so far never had a security hole and has been released and used by millions of people over the last seven years. Our security track record has so far (knock on wood) been a lot better than any of the other software in this area. Part of the reason we've achieved that track record is that we are conservative about adding new features and changing things. Getting nervous because we're not releasing a critical patch every month is... not the way we think people should be reasoning about security. :-)
keithw
on 2 Apr 2019
@keithw @cgull Did you make progress on the plan? :)
mxmerz
on 10 Jul 2019
Coming up on another 6 months since last comment; please make at least an alpha or candidate release to get the new features more tested!
robbat2
on 4 Jan 2020
Wondering if a release-manager has been nominated yet, or calls for volunteers for same.
javabrett
on 5 Jan 2020
Should this release from master be 1.3.3 or 1.4.0 based on semver rules?
javabrett
on 6 Jan 2020
@cgull @keithw @andersk friendly ping. are there any updates on cutting a new release?
mrueg
on 21 Mar 2020
Honestly, the progress of mosh development is so frustrating. The issues are piling and so does pull requests. I don鈥檛 mind compiling from source on the platform that I have control of.
The problem is from third party app that I rely on such as JuiceSSH & Terminus is still using release from THREE years ago. Can you imagine how long was that in this modern era?
I just want true color support. That鈥檚 it
Thank you
/RANT
kuntau
on 14 Jun 2020
I think there is room to fork the project at this point.
vvug
on 15 Jun 2020
I think there is room to fork the project at this point.
Fork won't solve the 3rd party app problem, they always use version from official
kuntau
on 15 Jun 2020
Maybe we need to change our CI so that we upload a new "release" on every commit. For people who are asking for new releases, does that solve problems, or create new problems?
eminence
on 15 Jun 2020
My thinking would be that this is not a great system for a security-focused piece of software -- it seems better for us to keep some control over the releases that people are running in the field. If the mere act of committing to master means pushing a release where we have to worry about a real-world impact from a hypothetical security hole, it seems like we will become even more conservative. I don't see a need for Mosh to be a leader on this before other security-minded software (OpenSSH, Chromium, OpenSSL) goes first.
But I mean of course but I would defer to @cgull . My understanding is that he plans to try to corral us towards a release sometime this year, with the hope of making Debian's next release (deadline likely to be early 2021). Commentators who lecture us about "modern" software development, would you also want the "modern" trend of monthly CVEs and emergency patches? :-) You are getting something in exchange for our conservatism -- a much better security track record than those other programs. It is not so black-and-white.
keithw
on 15 Jun 2020
Maybe we need to change our CI so that we upload a new "release" on every commit. For people who are asking for new releases, does that solve problems, or create new problems?
It's not ideal, essentially everyone would be running code from development. Software versioning exists for a reason, a big one being stability and lack thereof in development code. I assume it would also be annoying for maintainers of package managers to always have to update on every commit.
I think you're thinking in the right direction, but honestly I don't think we need to go that far. Just cut a new version from master, let it sit as RC for some time, and release it as a new version.
nthapaliya
on 15 Jun 2020
All good points. I'm just thinking out loud here, and wonder in practice what additional stability/security come with an RC then a release. For anyone that asks about true color support or other new features, I've always been recommending to use master, without giving any warnings about stability/security. mosh is taking so few new features these days that master always feels stable to me, but I can certainly imagine how that wasn't true in mosh's past (and may not always be true in the future).
You bring up a good point about package maintainers. An RC is a strong signal to them to start to prepare a new package and to do whatever package-specific checks are needed (and then gives them time to provide feedback to us).
Is there any reasons to not tag an RC right now? (I guess it may signal that we're preparing to create a release when we actually aren't 馃槃 )
eminence
on 15 Jun 2020
@keithw A very large fraction of those wanting a new release want it due to true color support, which is a relatively small patch (https://github.com/mobile-shell/mosh/pull/939/files). Do the security considerations still apply when doing a release just with a true color support?
cheshire
on 7 Jul 2020
FWIW, it seems the true color support was not merged directly: https://github.com/mobile-shell/mosh/pull/939#issuecomment-341920573
I just pushed your work, and some additional changes, to master.
I don't know how important the additional changes are, but I just tried a scratch build in Fedora with #939's patch, and it seems to work fine. I might ask Fedora's mosh maintainers to apply that, but of course a proper release would be nicer.
cuviper
on 30 Sep 2020
The rationale for release could be to add triaging bot and announce it. That can help mosh users with triaging and clarifying issues, most of which look like a support request or insufficient data.
Cutting a release once in a while is a good practice to calm users that the project is not dead, and security issues are still getting cared of. A pinned issue or a README.md might work for that as well.
abitrolly
on 17 Dec 2020
Related issues
cshei
路
5Comments
jscinoz
路
7Comments
pravi
路
5Comments
franzf
路
5Comments
shibumi
路
5Comments
Most helpful comment
@cgull and I should make a plan for a new release and figure out who is going to do the work (since I know a lot of people want 24-bit colors and other features that are only in Git), but this last comment is so confusing to me. Mosh has so far never had a security hole and has been released and used by millions of people over the last seven years. Our security track record has so far (knock on wood) been a lot better than any of the other software in this area. Part of the reason we've achieved that track record is that we are conservative about adding new features and changing things. Getting nervous because we're not releasing a critical patch every month is... not the way we think people should be reasoning about security. :-)