Release Version 1.3 #2728
Comments
|
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 1.2.0 came out in 2009-12-10 according to https://wiki.mumble.info/wiki/1.2.0 |
|
The predecessor to 1.3.0 would technically be 1.2.4. Not that that improves the situation dramatically. |
|
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." ProposalI 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. |
|
Would be awesome since the 1.2.x branch uses EOL version of Qt at least on Linux. |
|
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. |
|
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)... |
|
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. |
|
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: 1.3.0 bugs with priority P1: |
|
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.
|
|
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 |
|
Here's the explicit Debian bug about this issue: |
|
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? |
|
Remaining issues for 1.3.0: https://github.com/mumble-voip/mumble/milestone/1 |
|
No, the blockers are the P0 issues. |
|
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? |
|
Gentoo is dropping qt4 packages and thus also mumble: https://bugs.gentoo.org/656826 |
|
qt4 support ended two and a half years ago, it's really time to release mumble 1.3. |
|
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
|
|
Gentoo Linux has officially masked mumble < 1.3 and USE=mumble, blocking new installations of any version other than the upstream git repo |
|
@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 :(. |
|
@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. |
What he said! :) 👍 🥇 |
This has now been put into practice: |
|
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 |
|
sorry for the +1 and ALL CAPS, but i think it's worth it: YOU GUYS ROCK! THANKS SO MUCH FOR YOUR WORK!!! :) |
|
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. |
|
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). |
|
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: #3603 (comment) |
|
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 |
|
Thanks for keeping us updated. |
|
You're welcome. |
So I suppose we will soon see the same release files like we got for the |
|
Correct. The Windows and macOS files are missing because we have to sign them manually.
It was erroneously called |
|
Ah, I was looking here on GitHub in your releases section. Thank you for the link. |
|
You're welcome, I uploaded the files on GitHub. |
|
|
|
Nice! |
|
|
|
Great to see progress on 1.3.0-rc2. Any idea on when the final 1.3 will be released? |
|
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 |
|
Why is website redesign blocking the new release? |
|
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. |
|
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. |
|
Mumble 1.3 is finally here! |
|
And the new website as well! |
|
Great job guys! EDIT: Removed my incorrect statement about deps |
and others
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.
The text was updated successfully, but these errors were encountered: