mirror of
https://github.com/mumble-voip/mumble.git
synced 2026-03-03 00:46:56 -05:00
Release Version 1.3 #1092
Labels
No labels
GlobalShortcuts
Hacktoberfest
accessibility
acl
asio
audio
bonjour
bsd
bug
build
certificate
ci
client
code
documentation
external-bug
feature-request
gRPC
github
good first issue
help wanted
help-needed
ice
installer
linux
macOS
needs-ckeck-with-latest-version
needs-more-input
overlay
positional audio
priority/P0 - Blocker
priority/P1 - Critical
priority/P2 - Important
priority/P3 - Somewhat important
priority/P4 - Low
public-server-registration
qt
recording
release-management
server
stale-no-response
stale-support
support
task
test
theme
translation
triage
ui
windows
wontfix
x64
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mumble-mumble-voip#1092
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @EmperorArthur on GitHub (Jan 11, 2017).
Originally assigned to: @davidebeatrici on GitHub.
I'm creating this issue because I haven't seen it discussed anywhere else. If there is an active discussion please post a link to it.
Mumble version 1.3 has plenty of stable features that many users value. It has a dynamic system to keep plugins up to date automatically, channel filters, per user volume controls, etc. Unfortunately, the long time period between stable releases means many users are on version 1.2.
Many users use sites like mumble.com as their download source (It's the first result in a google search for Mumble), and those only serve stable versions. Barring any regressions, a stable 1.3 release should be nothing but a good thing.
Many users are moving to alternative products (Discord) from Mumble. Part of this is discord's web client, and persistent server. Part of it is their, ugly, UI design and the fact the servers are free. But at least part of it is the features discord has and Mumble lacks, like per user volume control.
Releasing a 1.3 stable release will being many new features to the users, and shows that Mumble has an active development community. Given the long time from the 1.2 release I feel that now is the time to proceed. There are only two main questions that need to be answered:
See Blocker and Critical issues.
@mkrautz commented on GitHub (Jan 11, 2017):
Yeah, we need to do a release soon and get on a proper schedule once again.
The way I see it, there are a few features (SRV records, overlay launcher filter) and a few bug fixes I'd like to get in before we cut a beta, and then we can, IMO, do a release.
@EmperorArthur commented on GitHub (Jan 11, 2017):
Let's see here.
For overlays, that's Issue #2059, #1953, #1954 and pull #2371.
For SRV records that's #1242, which someone attempted to implement via a QT5 only patch, number #1306.
I think that's it for those two features. Which bugs do you see as blockers?
@mkrautz commented on GitHub (Jan 11, 2017):
Bugs:
https://github.com/mumble-voip/mumble/issues/2199 - We need to verify whether the extra locking that was added fixed the problem
https://github.com/mumble-voip/mumble/issues/1874 - We need to remove NUL bytes in strings exposed via Ice - or mark some fields as deprecated and add sequence properties for them as an alternative.
@Tarun80 commented on GitHub (Jan 11, 2017):
@EmperorArthur 1.2.0 came out in 2009-12-10 according to https://wiki.mumble.info/wiki/1.2.0
@mkrautz commented on GitHub (Jan 12, 2017):
The predecessor to 1.3.0 would technically be 1.2.4.
1.3.0 was supposed to be 1.2.5, but we changed the versioning to allow us to release patch releases for 1.2.x for security and bug fixes.
Not that that improves the situation dramatically.
@Kissaki commented on GitHub (Jan 12, 2017):
Relevant 1.3.0 milestone
@EmperorArthur commented on GitHub (Jan 12, 2017):
There are currently 46 open issues, some of which date back to 2013. Of those, this thread has identified 6 major blockers.
Perfect is the enemy of good enough. To most users the project is stagnant right now. Given that the last stable feature release was 1.2.4 in 2013, I can't blame them.
For example, one feature Discord is touted as having versus Mumble is per channel audio volume. 1.3 has had that for quite a while, but when I checked with everyone I knew who used mumble they were all using 1.2. They didn't even know 1.3 existed, and were wary of trying a "Development Snapshot."
Proposal
I propose that all issues that do not block a 1.3 release be moved from the 1.3 milestone to the 1.4 milestone. This gives everyone a clear indication of things that are major priorities for the project.
@C0rn3j commented on GitHub (Jan 18, 2017):
Would be awesome since the 1.2.x branch uses EOL version of Qt at least on Linux.
@EmperorArthur commented on GitHub (Jan 18, 2017):
Wow, I didn't realize QT4's been EOL for an entire year. That's not a happy place for Mumble to be from a security perspective.
http://blog.qt.io/blog/2015/05/26/qt-4-8-7-released/
@jammet commented on GitHub (Jan 19, 2017):
I can only encourage you to produce a 1.3 stable release. Everybody I know is enjoying the snapshots, currently.
(Also because every single person I point to the download site doesn't seem to simply FIND the 1.3 release I tell them to download. Either that or they don't find the x64 version ... I'm not making this up :). No idea why, the download section seems to confuse a lot of people, and then I get asked why their overlay isn't working)...
@mkrautz commented on GitHub (Feb 7, 2017):
To provide an update to this, we've created new priority labels on GitHub. See https://wiki.mumble.info/wiki/Issue_Priorities for details.
I've applied labels to all the 1.3.0 milestoned issues. Some of them might be slightly off, but I think most of them are OK.
@mkrautz commented on GitHub (Feb 13, 2017):
The above rules state the in order to release 1.3.0, we have to fix the following bugs:
1.3.0 bugs with priority P0:
https://github.com/mumble-voip/mumble/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3A%22priority%2FP0%20-%20Blocker%22%20milestone%3A1.3.0
1.3.0 bugs with priority P1:
https://github.com/mumble-voip/mumble/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3A%22priority%2FP1%20-%20Critical%22%20milestone%3A1.3.0%20
@rburchell commented on GitHub (Nov 20, 2017):
It's now approaching a year since this was filed. As a long term software developer and open source contributor, I understand that a lot of work goes into making a high quality release, but I do wonder if that level of concern for high quality can make one overlook other (more immediate) problems.
I recently noticed that 1.2.x was using Qt 4 on Fedora (which as already mentioned is EOL, but also tends to provide a much worse experience[1] in my opinion than Qt 5 running on top of my own work, https://github.com/CrimsonAS/gtkplatform/), so I attempted to build against Qt 5, only to find that the 1.2 release has problems (since fixed I think, from looking around git) that prevent my doing that out of the box, and then found this issue which appears to be in limbo- and with several of the issues linked dating back a number of years, this doesn't look like it is going to be resolved any time soon.
With respect, I would suggest that it may be doing more harm than good in keeping releases in stasis indefinitely. I can't speak for everyone, but as a user, my first experience with Mumble was not a great one, I think it's safe to say, given the amount of work that has gone in since the last 1.2 release. And on the other hand: this also isn't a particularly encouraging state of affairs to me as a potential contributor: I have no desire to work on a release that has no chance of shipping seemingly indefinitely, but nor do I want to perform necromancy and work on an ancient release way behind the "latest" when it's probably not necessary to do so.
I'm not sure what I'm trying to say here, so I guess I'll just cut to it: my personal suggestion would be that getting a release out relatively soon - regardless of the open bug list - would be a good idea. It may have problems, but nothing is insurmountable, and the appearance of a slightly more "blessed" 1.3 that can make its way to end users wouldn't mean that 1.2 would vanish immediately for those that required it.
To make it clear, I mean no disrespect by this comment, I'm very happy to see that there's something open source in this space. I'm new to Mumble, and just felt that my perspective/$0.02 may be worth offering. I hope it's of some use.
[1]: here's a screenshot of a freshly started, connected but otherwise untouched Mumble instance. note the tiny icons, not-quite-native menus, and small window size meaning that text isn't easily visible.
@stikonas commented on GitHub (Nov 21, 2017):
Also please note, that KDE will soon release 17.12 version of its Applications which no longer ships any Qt4 based applications. After this, most GNU/Linux distributions will simply start cleaning up other unported Qt4 programs. See e.g.
https://wiki.debian.org/Qt4Removal
https://bugs.gentoo.org/631788
@EmperorArthur commented on GitHub (Nov 21, 2017):
Here's the explicit Debian bug about this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874683
@C0rn3j commented on GitHub (Mar 22, 2018):
It's now been over a year since this issue was open.
Qt 4 is still EOL, so I will repeat a suggestion in here - how about releasing 1.3 now and moving all current issues to 1.4?
Is there something seriously blocking the 1.3 release?
@ghost commented on GitHub (Mar 22, 2018):
Remaining issues for 1.3.0: https://github.com/mumble-voip/mumble/milestone/1
@mkrautz commented on GitHub (Mar 22, 2018):
No, the blockers are the P0 issues.
@killrhythm09 commented on GitHub (May 12, 2018):
So what's holding back progress on the blockers? I'm aware I have no right to complain about the state of the project since I'm not a contributor and it's free software, but as a long-time user of Mumble, it's been frustrating to see all my friends migrate to Discord while things have essentially stagnated here with no stable releases for a number of years. This issue itself is almost a year and a half old.
Is there anything volunteers can do to expedite the process?
@tillschaefer commented on GitHub (Jun 21, 2018):
Gentoo is dropping qt4 packages and thus also mumble: https://bugs.gentoo.org/656826
@malteme commented on GitHub (Jun 22, 2018):
qt4 support ended two and a half years ago, it's really time to release mumble 1.3.
@C0rn3j commented on GitHub (Jun 22, 2018):
So there are currently three blocker (P0) issues - https://github.com/mumble-voip/mumble/issues?q=is%3Aopen+is%3Aissue+label%3A%22priority%2FP0+-+Blocker%22
@LucasToole commented on GitHub (Jun 27, 2018):
Gentoo Linux has officially masked mumble < 1.3 and USE=mumble, blocking new installations of any version other than the upstream git repo
https://bugs.gentoo.org/656826
https://packages.gentoo.org/packages/media-sound/mumble
@stikonas commented on GitHub (Jun 27, 2018):
@Ojoesinco Well, upstream git repo version is also not keyworded. There isn't that much difference for users between masked and not keyworded...
But unfortunately it doesn't look like mumble project cares about being removed from distros :(.
@reelsense commented on GitHub (Jun 29, 2018):
@stikonas I've had a very simple PR open since last year... It's a PR that adds a bot to close all this unimportant crap that they don't just make a decision on after X amount of months.
Their indecisiveness is very off-putting. There must be some politics that we're not clued into. I'm closing my PR because I'm tired of looking at it. They can reopen it if someone takes control.
@AzP commented on GitHub (Jun 29, 2018):
Hi, I came here as a Gentoo user who's forced his friends to install Mumble for playing a couple of games, that is about to have it uninstalled since Qt 4 is going out the window... I hope you guys can push for a 1.3 release, and then perhaps fix the most critical issues in a 1.3.1 within a couple of weeks.
I appreciate your work!
@reelsense commented on GitHub (Jun 29, 2018):
I appreciate Mumble a lot as well! I'm just frustrated trying to guess what's happening from the outside.
(Sorry off topic.)
@Kissaki commented on GitHub (Jun 30, 2018):
Let me just say sorry for the lack of information, leadership and stable releases of this project.
Unfortunately, this is pretty much just as frustrating for us, if not more, than for our users. We contribute our free time and have to manage and prioritize what we can and should work on, also caring for ourselves. Sadly, we currently do not have people committing enough time per week for this, and no strong leadership either. We are not funded. We struggle - as is blatantly visible.
We do hear you, and talk internally about if and how we can improve the situation. We are all limited on time. We did talk about that some kind of leadership role with committed time and decision power could help, but we don't really have someone to fill that role.
While I would like to work on Mumble full time, or part time, that is not the reality I currently live in. I have a full hour week, as a software engineer as well, so in the evenings and weekends, it should be more than chores to work on, and some other stuff as well to stay healthy. Even working on simple features can be a lot of effort and is really frustrating when you realize it is not so simply done - after all Mumble is quite complex already, and there often are multiple things to consider.
When I do reviews I also have the expectation of myself to do it thoroughly. That often means investing time into investigating and thinking about the premise, the implementation, possible issues with our usability or technology, etc. It often feels like a chore.
So yeah, I don't know what else to say. It's frustrating for all of us. We're trying out best, in the time we feel comfortable to spend.
@C0rn3j commented on GitHub (Jun 30, 2018):
@Kissaki
Thanks for trying to stay in touch with the community via the messages and the Px tag system.
I'd however like to highlight something that was suggested here - Why not (at least for one time, since the last proper release is years behind) ignore all the bugs, release 1.3 and deal with the issues that stem from it after?
I think just releasing 1.3 is a way lesser evil than letting the project rot for the following reasons -
Pros:
Distributions have already started dropping Qt4 apps
I can't imagine using a long-EOL framework is great from a security standpoint
Cons:
It's got to the point where Linux users are starting to have issues installing Mumble in the first place, I believe I'm speaking for the vast majority of users when saying that we'd prefer slightly buggy release than a dead project.
While this is perhaps a whole another issue, you mentioned lack of funding. Other FOSS projects have managed to stay afloat by simply asking for money and being transparent about their goals and what they want to use the money for.
Namely Krita and their usual kickstarters, RPCS3's Patreon, and GIMP at least has a donation page where they point at their member's fundraisers/donation_pages.
Maybe doing a fundraiser should be considered so the project could hire a lead?
@Kissaki commented on GitHub (Jul 6, 2018):
Just to drop in some more infos on what I am working on: I want to fix our Ubuntu PPA builds before checking this ticket and it's blockers specifically, and coming to a decision or work here.
For the PPA I did do some analysis last weekend, and… let’s just say it’s more complicated than I would like (see #3433). But I’ll work on that before here on this ticket.
@Kissaki commented on GitHub (Jul 6, 2018):
I agree that we should "just" release "something". We have to move forward. Even if that means sacrificing some quality or higher risk or missing out some stuff.
@Kissaki commented on GitHub (Jul 6, 2018):
Just to throw this out here as well: Releasing may be problematic atm though, as part of our build infrastructure is missing, and the developer that hosts them is MIA. We can't use the previous workflow and are missing the binary signing certificate AFAIK. That will have to be worked out as well.
@stikonas commented on GitHub (Jul 6, 2018):
@Kissaki Does this prevent automatic upgrades from 1.2 (if so then it's more problematic)? Or is it just for GPG signing files, so that people can check if they want.
@Kissaki commented on GitHub (Jul 6, 2018):
Windows verifies downloaded file signatures. When introducing a new certificate, Windows will deem the file "not safe" until it has some numbers of trusted installs, has seen the signature a few times.
We briefly had this when switching from our previous cert to the current one.
Other than that, introducing a new certificate is not technically a problem.
@marado commented on GitHub (Jul 8, 2018):
@Kissaki It at time of release the missing certificates are still an issue, maybe we could have 1.3.0 released for the other OSes, but delay the Windows release a bit longer? After all (if I understand correctly) the biggest urgency for 1.3.0 comes from Qt's EOL, and that isn't such an urgent issue on Windows...
@Kissaki commented on GitHub (Jul 8, 2018):
Yeah, I agree. That would be viable.
As we are technically backwards compatible, using older clients with newer servers is not an issue either.
@hacst commented on GitHub (Jul 8, 2018):
Before considering not releasing the new version for the platform the vast majority of the users are on we might want to try more active methods of raising said developer. E.g. actually email him or sth. ;)
@hfox commented on GitHub (Jul 12, 2018):
If there's still problems with this, I'd like to see 1.3.0 released for non-windowses ASAP.
@funkydude commented on GitHub (Jul 16, 2018):
Mumble is dead, stop beating the poor horse. It served us well, but everything dies eventually.
I warned this would happen at least 10 times over the past 5 years, but I'm not here to say I told you so.
WebRTC is the future, if you don't like that, tough luck.
We already have 2 great and popular clients that implement both security and ease of use well (Slack & Discord).
Skype has moved to WebRTC, virtually every phone app is implementing calling via WebRTC.
You can even find free to use web platforms such as https://meet.jit.si/ (yes, even the old "skype alternative" is now using WebRTC)
Let this die.
If you're obsessed with having something fully OSS or self hosted, make a new project based on WebRTC, you could easily and quickly whip something up using Electron for the client, and work on the server side of things for people who basically want a "self hosted Discord".
Alas this advice will probably be ignored/yelled at as my previous warnings were but perhaps someone with a passion will read this and be interested in pursuing such a goal. It is literally the ONLY advantage you could use as a selling point over Discord - privacy.
@reelsense commented on GitHub (Jul 16, 2018):
@funkydude You are mistaken.
@Kissaki Could you soft-launch the Windows binary signed with the new key? Let all the people in the know install it to try and get the signature recognized?
@funkydude commented on GitHub (Jul 16, 2018):
@reelsense Haha, déjà vu
Give it another 2-3 years and we'll see the download stats, if it even exists.
@LEW21 commented on GitHub (Jul 17, 2018):
@funkydude There is Mattermost, and I hope it will add voice support soon.
@main-- commented on GitHub (Jul 17, 2018):
@funkydude Isn't it a bit hypocritical to decry anything that isn't WebRTC as outdated, dead even, while you're still here using IRC which is literally 30 years old and also threatened by newer web-based solutions?
@VwieVendetta commented on GitHub (Jul 19, 2018):
WebRTC? You mean that protocol which still features IP leaks?
Slack and Discord? Just a bunch of average proprietary messengers lacking security/privacy.
Here's a list with dozens of messengers and you'll immediately notice that neither Slack nor Discord are secure or special in any way:
https://docs.google.com/spreadsheets/d/1A3xz8NFWjebuMbGWvy2yUBKcnAmuZSs5JmKq9-JDss8/edit#gid=140745845
(I know it's ugly, but secured.fyi is getting a facelift right now)
Slack
The crypto-messenger Wire - recommended by Snowden - portrays Slack's shortcomings in a small table:
https://wire.com/
Slack is definitely not suited for professionals.
Discord
Just another one of Jason Citron's schemes. It's amazing people still fall for his money making methods. Asphyxia from r4p3.net has taken a closer look at Citron and his past business practices:
https://linustechtips.com/main/topic/586044-why-discord-sucks/
Discord is nothing more than a badly programmed messenger for children who are not tech-savvy. You can't tell me the childish texts, the GUI and the lack of customization are geared towards adults or power users. Besides, Discord doesn't protect your privacy in any way. Everything is saved openly forever on their servers and the data can be searched with ElasticSearch. I do admit that Discord is popular among hackers:
https://www.symantec.com/connect/blogs/attackers-use-discord-voip-chat-servers-host-nanocore-njrat-spyrat
Causing damage has never been so easy.
Did I mention that Discord is unusable every couple of weeks due to server problems? That happens when you're making yourself a slave of a greedy corporation with a centralized platform. In order protect the sensible Discord users, they censor inappropriate content. Now they even want to use machine learning in order to get rid of "potentially harmful" pictures.
In a time in which censorship and fascism arise, the future lies in decentralized (HubZilla, Mumble etc.) or even distributed (Ring, Tox etc.) platforms.
Mumble is not a universal messenger and doesn't want to be. It's the messenger for smart gamers which need lowest possible latency, excellent scalability and minimal resource usage. There are several reason why the big EVE guilds with 1000+ members are using Mumble: it's lightweight (powerful and performant C++ + Qt instead of Discord's slow and bloated JS + Electron), much more secure (perfect forward secrecy) and features lower latency as well as better audio quality than the competition. Did I mention the fact that Mumble is perfectly geared towards guilds? You can link channels and create a fine command over several hierarchies. Besides, Mumble is free, open source, can be improved with plugins, bots and themes and it features positional audio which increases immersion. Now those are killer features Discord can't compare with. Murmurd even runs well on a weak Raspberry Pi 3.
Mumble is here to stay if no serious competition arises. I'm going to laugh so hard at the Discord kiddies when the investors (for example infamous Time Warner) want to see cash. Discord still hasn't any business plan and some stickers or Nitro (who pays money to be robbed and to get access to basic features good messengers offer for free?) just won't cut it.
@ALRBP commented on GitHub (Jul 20, 2018):
Well. Discord is working perfectly fine on my Gentoo system. When I installed Mumble, the Push-to-talk (mandatory for me) was not working and now, Mumble is planed to be removed from Gentoo due to it depending on long time deprecated Qt4 (it was the last blocker for Qt4 removal on my KDE Gentoo system).
Discord may be proprietary (at least they are using Opus) but it seems that it is presently more Linux-friendly than Mumble!
I can't tell my co-players to use Mumble instead of Discord because FOSS is better if Mumble actually works much worse on my FOSS Linux OS than Discord! Maybe I should try running the Windows version of Mumble with Wine?!
For me, if Mumble is not updated to use Qt5, it will die as it deserves. I can't advocate for an out-of-date software.
I am convinced that Discord will reveal itself as a bad choice in the future. The company being it will not provide free server without counterpart forever. But for now, Mumble is not enough actively developed and Discord is working (and privacy is not critical for gaming voice chat ; it is not the same for other applications).
I hope either Mumble will be more actively developed or a new FOSS voice chat client-server will be created and ready on time to replace Discord in the future.
@funkydude commented on GitHub (Jul 20, 2018):
@ALRBP The only real issues with Discord are privacy and centralization (entire regions go down)
There's next to 0 proprietary code in the client, it's a web view using WebRTC via Electron, the bulk would be the server code which we can't read. Him calling it "badly coded" is also laughable when you're talking about running JS and HTML in a sandbox vs Mumble. When was the last time Mumble was audited exactly? Let's best hope that never happens =P
It's also far more secure than Mumble, using superior voice encryption. It will also soon be moving to TLS 1.3 for non-voice, good luck seeing that in Mumble in any reasonable time frame. The current release of Mumble doesn't even implement Forward Secrecy hahaha.
But there's no convincing people that write a post about how they are superior human beings for their software selection whilst at the same time thinking revealing an internal IP address is an issue (welcome to IPv6).
@main-- commented on GitHub (Jul 20, 2018):
Can someone mark all of this as off-topic? It's really not relevant for the 1.3 release.
@Kissaki commented on GitHub (Jul 20, 2018):
Yes, please keep this on-topic. Not sure how to handle these that have already been posted, but I will remove any off-topic replies that will follow. So put that effort somewhere useful instead.
@Kissaki commented on GitHub (Jul 22, 2018):
From the issues linked to in comments two and three in this thread, only #2199 is open and critical/important (also labeled critical; see below).
In the 1.3.0 we currently have one blocker, and seven critical.
I think two are mislabeled. They are not critical. I raised that concern in them.
We should take a look at PR #1765, which mkrautz raised issues for final fixup before merge. So finishing that up should be fairly simple/reasonable.
We should check on #2865 #2199 #1679. I’d like to at least evaluate these before tackling a release.
@Kissaki commented on GitHub (Jul 22, 2018):
For #2199 changes were made, but the issue was not reproducible in old or new version, so we are still missing a test case. But nobody else reported it since. So not a blocker.
@necrose99 commented on GitHub (Aug 9, 2018):
https://www.kdab.com/un-deprecate-qt-project/ few scripts to port qt4 to qt5 in a project.
@stikonas commented on GitHub (Aug 9, 2018):
@necrose99 Mumble was ported to Qt5 some time ago. Just not released, so probably these scripts are not useful at this stage.
@necrose99 commented on GitHub (Aug 11, 2018):
np @Gentoo been Getting AXE'y with most of QT4 related items... but swweet media-sound/mumble media-sound/murmur looks like ebuilds moved to qt5 anyhow.. https://gpo.zugaina.org/media-sound/murmur
@edm7707 commented on GitHub (Sep 17, 2018):
Any info on progress towards a 1.3 release?
anything going on behind the scenes?
@malteme commented on GitHub (Sep 23, 2018):
One blocker is still remaing: https://github.com/mumble-voip/mumble/issues/2865
There are also four open issues marked as critical, but i am not sure wether they would block a release or not.
@Kissaki commented on GitHub (Sep 23, 2018):
I don’t consider any of them blockers (unless there are new ones I'm not aware of yet).
@AzP commented on GitHub (Sep 29, 2018):
Perhaps you can push a beta (or release candidate) out, disregarding signings, dependencies on different OSes (I assume Windows is the most downloaded client anyway, even though I'm pure Linux myself), just to get something out there for testing (and building).
Tagging a 1.3 release in Github would at least allow for instance Gentoo (and other rolling releases) to ship a new package version, since they're building from source anyway.
@ALRBP commented on GitHub (Oct 6, 2018):
Actually, Gentoo is now only providing the latest Git version ("9999") in portage, due to Qt4 deprecation. This version is masked by default and considered unstable but I find it actually working better than 1.2 on my system (solved a seriously annoying bug preventing push-to-talk from working, no bug spotted so far).
1.3 may not be perfect if released now, but it would still be better than the severely outdated 1.2.
Some Gentoo people actually suggested to make their own snapshot of mumble Git, so they could have a working "release" that could be "keyworded" (~arch, marked for testing) or stabilized (the Git version cannot, since it's constantly changing). Quite a shame that some distribution maintainers would have to do their own "release" due to upstream not making one.
@Seeboetiu9Ethaew commented on GitHub (Nov 3, 2018):
It has now even been almost 2 years since this thread was started. Isn't it time to bite the bullet, guys?
@ghost commented on GitHub (Nov 19, 2018):
ne they need lanconf to fix the final networking upgrades that have people iceskating across the map when u let go of W.
@C0rn3j commented on GitHub (Dec 7, 2018):
If there's no blockers, why not finally tag a release and work from there?
It would be a shame if Mumble ended up like DD-WRT and never releasing a stable version again.
@malteme commented on GitHub (Dec 9, 2018):
I think he was referring to the priority P1 issues. Unfortunately there hasn't been any progress on #2865 because of missing manpower.
@main-- commented on GitHub (Dec 30, 2018):
By the way, FreeBSD's
audio/murmurport is now deprecated (due to depending on the EOL qt4) and scheduled to be removed (!) on 2019-03-15. I very much agree with the sentiment in https://github.com/mumble-voip/mumble/issues/2865#issuecomment-447454729 - dependency management is going to be up to distro maintainers in most cases anyways so it shouldn't matter too much.@anarcat commented on GitHub (Jan 16, 2019):
i don't see why mumble dependencies should block a release. at least do a beta or rc or something already... :)
@Kissaki commented on GitHub (Jan 23, 2019):
As an update: We recently did some fixups on our release build environment, which was broken. Unfortunately our binary signer is down again, which we have to fix before we can do releases. But our plan is:
@AzP commented on GitHub (Feb 8, 2019):
May I ask what a "binary signer" is, and how it can be down? Are there no alternatives?
Btw, looking forward to the release and seeing progress! <3
@davidebeatrici commented on GitHub (Feb 8, 2019):
The binary signer is up and running, we released a new snapshot some days ago.
It's a Linux machine we use to sign the installer (and its contents) built by our Windows machine.
@Kissaki commented on GitHub (Feb 8, 2019):
To elaborate: Windows has a concept of trusted applications. When you download a program that is not signed, when you try to execute it it will warn you that it is untrusted, and strongly suggest not running it unless you know what you are doing.
So publishers buy a code signing certificate from a trustworthy source that, to some degree, verifies the buyers integrity. The publisher is then able to sign their binaries and installers with the certificate, and windows will recognize the signature as issued by a trusted party, and accept the binaries as trusted - silently to the end user.
Hence we have to keep our signing certificate safe, in a mostly isolated environment. As a result "fixing" it can be more challenging than other parts of our build system (specifically because at the moment only one person has full access to the box that actually runs our signing. More of us have access to the certificate and could theoretically replace the signer if need be, but we had to wait on one person to fix the existing box).
@AzP commented on GitHub (Feb 8, 2019):
Aah, I just found that on the website via the wiki. Thanks for the tip.
Is it possible for you to tag the snapshot releases in git, so we're able to prepare packages for it for Gentoo? I figured I'd write an ebuild (or update existing), so it's easier to test out.
@Kissaki commented on GitHub (Feb 9, 2019):
I’m not sure that tagging snapshots is viable/a good idea.
Development snapshots are meant to be on the development edge, fast moving, and temporary. So tagging may not be a good idea. It’ll make our tag list explode.
I’m not sure how you would plan to publish Gentoo packages in that regard? Is that something that is done for other packages? A separate release? Or are those releases then marked/versioned as lower-priority to stable releases? From a build and release standpoint.
I would say always building and releasing from the
masterbranch is more viable then - no need for snapshot tags. We do not depend on snapshots being the same code base across platforms. And versions should receive an appropriate version label; like counting the number of commits, etc. See the Windows snapshot version labels.@dvzrv commented on GitHub (Feb 13, 2019):
Development snapshots, yes. I think what @AzP was referring to is tagging a release candidate or a proper release.
Analogouos to what @main-- was referring to, Arch Linux (amongst many other Linux distributions - some already dropped qt4 months ago) is also on its way to deprecating all qt4 related things currently.
Given the fact that two years and nearly 3000 commits have passed since the last stable release, I guess it's not too much to ask for a new stable release tag ;-)
Please do!
@AzP commented on GitHub (Feb 15, 2019):
What he said! :) 👍 🥇
@Polynomial-C commented on GitHub (Mar 13, 2019):
This has now been put into practice:
github.com/gentoo/gentoo@deee516a43github.com/gentoo/gentoo@5446943a3e@Kissaki commented on GitHub (Mar 17, 2019):
As a status update: The RC we tagged and then revoked two weeks ago and showed that one of our build scripts did not adequately support git tagged releases. It constructed the version name as if it were a snapshot.
One of our team members was fixing it, but ended up not being able to do so because of time.
Today I fixed it. It has been reviewed and applied.
So I think we are looking at tagging and trigger another RC
in the coming daystoday.@anarcat commented on GitHub (Mar 17, 2019):
sorry for the +1 and ALL CAPS, but i think it's worth it:
YOU GUYS ROCK! THANKS SO MUCH FOR YOUR WORK!!! :)
@Mikki-black commented on GitHub (May 15, 2019):
Great to see a 1.3 RC1 but it has almost been 2 months. Is there a blocker issue I missed for not releasing an official 1.3? It would be great to have an official 1.3 release.
@davidebeatrici commented on GitHub (May 15, 2019):
#3603
@Kissaki commented on GitHub (May 19, 2019):
To be honest if it's a blocker for Mac, but we have no testers for the PR, we should finish up the release for other platforms and skip Mac. Mac only with no testers available shouldn't be holding up all other platforms (that actually have users and testers).
@davidebeatrici commented on GitHub (May 19, 2019):
MacStadium kindly provided us a free Mac Mini as part of their open source project: https://www.macstadium.com/opensource
I tested the pull request and reported what has to be fixed: https://github.com/mumble-voip/mumble/pull/3603#discussion_r282356606
@davidebeatrici commented on GitHub (Jun 25, 2019):
RC2 has not been released yet because the signer machine is offline again and unfortunately we're unable to contact @mkrautz.
We already planned to put together a new build infrastructure with Azure Pipelines, but we are currently working on the CMake project (and the new build environment: https://github.com/mumble-voip/mumble-releng-experimental), thus we believe we should wait until it's ready.
I tagged
1.3.0-rc2and triggered the build, we will manually sign the releases.@malteme commented on GitHub (Jun 25, 2019):
Thanks for keeping us updated.
@davidebeatrici commented on GitHub (Jun 25, 2019):
You're welcome.
@Polynomial-C commented on GitHub (Jun 26, 2019):
So I suppose we will soon see the same release files like we got for the
1.3.0-rc1release? I'm especially interested in amumble-1.3.0-rc2.tar.gzfile.@davidebeatrici commented on GitHub (Jun 26, 2019):
Correct. The Windows and macOS files are missing because we have to sign them manually.
mumble-1.3.0-rc2.tar.gzis already available: https://dl.mumble.info/mumble-1.3.0-rc2.tar.gzIt was erroneously called
mumble-1.3.0.tar.gz, sorry for that. We have to fix the automated script.@Polynomial-C commented on GitHub (Jun 26, 2019):
Ah, I was looking here on GitHub in your releases section. Thank you for the link.
@davidebeatrici commented on GitHub (Jun 26, 2019):
You're welcome, I uploaded the files on GitHub.
@davidebeatrici commented on GitHub (Jul 3, 2019):
1.3.0-rc2for Windows now available.@mfr-itr commented on GitHub (Jul 3, 2019):
Nice!
@davidebeatrici commented on GitHub (Jul 5, 2019):
1.3.0-rc2for macOS now available.@Mikki-black commented on GitHub (Aug 13, 2019):
Great to see progress on 1.3.0-rc2. Any idea on when the final 1.3 will be released?
@davidebeatrici commented on GitHub (Aug 14, 2019):
We are working on the new website, 1.3 will be released as soon as it's ready to be deployed.
You can check out the repository here: https://github.com/mumble-voip/mumble-www
@C0rn3j commented on GitHub (Aug 14, 2019):
Why is website redesign blocking the new release?
@davidebeatrici commented on GitHub (Aug 14, 2019):
We believe the redesign is mandatory after 1.3 has been so many years under development.
The current website (our Wiki's homepage) is not very clear (e.g. the download links) and it misses quite a few things, such as screenshots and general information about the new version.
@Kissaki commented on GitHub (Aug 23, 2019):
I cleared out the 1.3.0 milestone (all tickets, which we do not intend to wait for/fix) and added two tickets #3758 and #3759 to make it clear what we intend to do/wait for. This comment is to keep the followers of this ticket updated. :)
I didn’t like either ticket blocking the release. I was initially tempted to just push for a release, no matter the cost or lack of quality. But we need the changelog for a reasonable release, and combining the release with the website release is a chance we should not miss.
We don’t have to make either perfect, as long as it is reasonable and provides good value - which will already be a big improvement to the current state or a release without a reasonable changelog/release change information.
@malteme commented on GitHub (Sep 8, 2019):
Mumble 1.3 is finally here!
https://github.com/mumble-voip/mumble/releases/tag/1.3.0
@davidebeatrici commented on GitHub (Sep 9, 2019):
And the new website as well!
https://www.mumble.info
@C0rn3j commented on GitHub (Sep 9, 2019):
Great job guys!
EDIT: Removed my incorrect statement about deps