Mumble: Release Circle/Policy

[toby63]

I noticed that the last release (1.3.0) seems to be from September 2019, so almost half a year ago.
At the same time i noticed that the master is over 300 commits ahead.
So the question is can and should new versions be released more often?

I want to add that I see some bug fixes (disputable what bug fixes are, at least one), depency updates and useful changes in the commits, for example #3989 commit.
So more recent new versions would be useful.

By the way I don't see snapshots as equal alternative, because thats not what most users will use.

[Krzmbrzl]

Well considering how long it took to release 1.3 I think we still have plenty of time :P
Jokes aside. You are of course correct that more regular releases would certainly benefit the project and its users.

Let me also tell you why (I think) there haven't been any intermediate releases yet:

1. We are a very small Dev team (currently only 2-3 devs of which one is/was busy with ajother full-time employment and one who just recently has found time to work on Mumble again. And me having joined the party only more or less recently am mostly busy with developing the new plugin framework and only taking minor things up as I go)
2. We (that is mostly davidebeatrici and ZeroAbility) are working to port Mumble to the cmake build system which will make building the projec (especially on windows) much much easier.
3. There haven't been any snapshot releases (due to point 2 mostly) and thus most features and fixes are tested only briefly on the devs machine. That's not really a state in which you want to draft a release from it

I think point 2 is actually the main one holding up any (snapshot) releases. I think once this has been taken care of, we'll see snapshot releases again and once we have had them to verify that the new code is stable I also think that we'll have regular releases again as well.

[toby63]

Ok, thank you for the explanation.
I also want to say that i appreciate your work very much and i am glad that this project is still active.
Nonetheless I wanted to draw attention to this issue, because some (especially open source) teams have a concept of only releasing major feature releases and I think that is wrong.

Pro arguments are:

• users get improvements faster
• newer releases look better, so users feel that a project is still active, instead of seeing very old releases (to be precise in this project the releases are only "older" and not "very old", but there notorious projects, you know what i mean)

Proposals for Improvements regarding release circles:

• Communication:
  Of course no specific deadlines are needed (because this is an open source project), but more communication about what is worked on and what the next (specific) goals are, would be good.
  You have already a page on the website wiki link, but it is nearly empty.
  I suggest a wiki page here on github, with a "todo" list for whats being in the works now and for the next release number(s).
  To be more precise, I don't expect long texts of explanations, just what you wrote here, like "port to cmake" etc.
  This could maybe also lead to more help for you, because i am sure that at least some users of mumble can code.

Regarding testing:
I am sure some users (like myself) would do some testing to, but I haven't seen any public communication about this, so I don't know if thats an issue or whether you have testers or even want testers or if this just done with the snapshots (?).

[Krzmbrzl]

Personally I agree that more small releases are usually better than few big ones. I guess the biggest problem here is that someone has to take the time it takes to draft a release with all that belongs to it (select what goes in it, builds for all supported platforms, announcement, changelog).
I can't say much about how this will be handled in the future without the rest of the team stating their views as well (which is why I marked this issue as discussion).
Maybe @davidebeatrici and @Kissaki could comment on this topic as well? :)

I suggest a wiki page here on github, with a "todo" list for whats being in the works now and for the next release number(s).

Well we do have milestones set up: https://github.com/mumble-voip/mumble/milestones.
They are probably not that telling though as things might get worked on without being in a Milestone simply because you see an issue and be like "oh that I can fix real quick" :man_shrugging:

Regarding testing:
I am sure some users (like myself) would do some testing to, but I haven't seen any public communication about this, so I don't know if thats an issue or whether you have testers or even want testers or if this just done with the snapshots (?).

I don't actually know how this has been handled in the past (aka before I started working on Mumble in the second half of last year) but I expect snapshots to be a very convenient way of getting testers onboard. Without snapshots though I think it would be rather hard to get willing testers as they'd have to be able to build mumble for themselves...
But as I said: I expect this whole thing to become better once we ported to cmake.

[toby63]

I guess the biggest problem here is that someone has to take the time it takes to draft a release with all that belongs to it (select what goes in it, builds for all supported platforms, announcement, changelog).

Ok, I understand. My first impression was, that the most work is already done (with the commits themselves), but I see that you are right, a release includes more work.
Nonetheless I hope the team considers a change, so that the next version is not coming in 2 years.

Well we do have milestones set up: https://github.com/mumble-voip/mumble/milestones.
They are probably not that telling though as things might get worked on without being in a Milestone simply because you see an issue and be like "oh that I can fix real quick" man_shrugging

My bad, I'm sorry, I sometimes forget about these "categories" of github when i haven't been on the site for a while. And somehow I oversaw that... :sweat_smile:

But as I said: I expect this whole thing to become better once we ported to cmake.

Ok. Then we can look forward once that is done.
Ultimately it is of course your decision what you focus on, but that is also a point of this issue, to discuss the focus (for example 1.3.1 vs. 1.4.0).
I still have to admit, that I have lesser knowledge about what is important.
As a user I only see the functions that are important to me, so for example I would have never thought about something like CMake being a priority (which it of course is).

Edit: As I see in the Milestones for 1.3.1 a release might not be that far away. So maybe my issue is solved. But I will wait for other statements from the team.

[Krzmbrzl]

1.3.1 actually only contained 2 issues at the time you opened this discussion here. I just took it as motivation to dig through the commits that have been made so far and pick those that I thought senseful to be included in 1.3.1 ^^

[toby63]

1.3.1 actually only contained 2 issues at the time you opened this discussion here. I just took it as motivation to dig through the commits that have been made so far and pick those that I thought senseful to be included in 1.3.1 ^^

Thanks for the clarification and especially for supporting v1.3.1.
I am curious, whether the rest of the team will agree.

[Kissaki]

Alright, to add some context here for you @toby63

Doing few releases is and never was an intentional decision but a result of various factors. We are under-staffed.

For 1.4.0 specifically we are completely changing our build system to CMake and a new build environment preparation (mumble-releng -> mumble-releng-experimental). This is a blocker. So until we finish that work we can not release 1.4.0.

1.3.0 took so long for various reasons. Unfortunately with time it gets harder to release both in terms of risk as well as work, and we also had issues with our internal build and release infrastructure which we had to solve multiple times.

We always would have liked to release more often. But it’s not a simple press-button-to-release. There are decisions, risk and documentation involved which is work, and more often than not there is other practical and technical work involved as well.

[Stefan-comkmits]

1.3.1 RC1 Says by every start theres a new Version detectet.
This is the Reason why i againts Auto Updates and messages about new version.

[Krzmbrzl]

1.3.1 RC1 Says by every start theres a new Version detectet.
This is the Reason why i againts Auto Updates and messages about new version.

1. This doesn't really belong in this issue.
2. You can disable the auto-update check in the settings
3. Once 1.3.1 is actually released, this won't happen anymore (provided that you'll be running 1.3.1)

[toby63]

@Kissaki: @Krzmbrzl already explained some of the mentioned topics above.
Anyway I understand your situation and ones again I want to say that i appreciate your work very much.
And I also understand if there is a lack of time or manpower to do something.

But still I think that this is a valid discussion.
If there are many commits (like in this project) it is not really a good thing, to only release a new version every 2 years (second-worst-case assumption).

So I recommend laying out an internal plan, for a release circle every six months.
This does not have to be a hard schedule, it can be delayed (in case of important things) or skipped (in case there are too less commits).
But it would change the focus.
Smaller steps instead of veeery big steps.

To clarify:
By a plan I don't necessarily mean a feature- or change-list that should be included at a specific date.
Instead I favor a strategy of "waiting" and then taking a look at what is there (for example one month before a normal release date) and then decide if there could be a release or not.

[Kissaki]

We talked about release strategy yesterday in our team meeting, the release strategy we want to target. We want to target a regular six months release cycle. To start with this we still have the blocker of our new CMake build system.

We also talked about milestones not being seen as blockers. We never strictly did see them as such, but they may incentivise waiting for stuff. We want to instead focus on releasing what we have. We are not a paid, full-time/committed time team so the plannability that milestones could provide is somewhat limited in that regard.