Change stability concept.

[Gabrielxd195]

Hi all. I understand that stable 1.2 will soon be released, but after that, what will happen ?, we will continue with the same release model? ... Currently the last release of an official version and downloadable from the repositories is version 1.1.3; however this version is already obsolete, and the RC versions have been improved and many errors have been corrected to the point that the trial version is more stable than the official version. I do not come to give a '' technical '' opinion nor am I a developer, but neither do I have to be a great genius to notice the following problems.

That I've seen?.

• Only rc receives maintenance, while stable is obsolete.
• The rc version exceeded the official stability.
• The rc version is not downloadable in the repositories.
• I have seen many users download more version 1.1.3 for being the official one and for being called '' stable version ''.
• The stable version 1.2 is delayed due to the fact that problems are added to the list. that is seen in milestone 1.2.0 and the percentage does not go from 96% to 98%, I see that there are always delays.
• The time period of each release is very long and random, due to the large number of problems corrected in each release.
• In each release errors are corrected, but also new errors appear and we have to wait until the next launch.
• They are not prioritizing correctly, because there are errors and improvements more urgent than others that are not taken into account.
• Many improvements and features are rejected even if they are well tested.
• Many improvements and important errors are being postponed to stable 1.3.

What have I read?

I have read some comments such as:

• '' Stable 1.2 will not have new improvements, it will only focus on the correction of errors ''.
   However, in the rc, some improvements have been added that do not affect the stability of LMMS.

• '' There can not be new errors in stable 1.2 ''.
  Even without adding anything new, errors have been corrected in each release but other new errors have been found.

• '' If we add new improvements, the release of stable 1.2 will be delayed ''.
  So far no major improvements have been made in the rc, and yet there have been many delays, and we see that in milestone 1.2.0. however, its launch was delayed.

My personal opinion.

As I said at the beginning: I can not give a technical opinion because I'm not a developer. but I have noticed that the problem is not the lack of new features, but the prioritization of problems and improvements, and the mistaken concept of '' stability '' that LMMS currently has. It is necessary to change it, because:

 '' The stability of a program depends on the maintenance of its developer ''.

Currently the 1.2 rc receive maintenance to become the next stable, to then repeat this long and late development process in the next stable 1.3, and while each rc takes too long to launch. we must understand that there will never be a perfect launch. and this model of releases is inadequate and delays the development of LMMS, and more than this project is of few developers, so we must change it because it is not feasible.

So, what do I suggest?

Launch stable official 1.2 as it is now. after being examined and reported by users, instead of releasing independent rc versions of the next official stable version 1.3, better make periodic updates to the official version stable 1.2. and the characteristics of these updates are:

• Each update will have a small amount of improvements and corrections, to reduce the release time period.
• The errors and improvements must be by priority order, that is: from greater to less urgent.
• Possibility to download the updates from the repositories.
• Updates must be renamed, for example: 1.2.0, 1.2.1, 1.2.2, etc.
• Merge any improvement as long as it has been stabilized.

While in the development version of LMMS, the improvements are tested and errors are corrected that take more time to develop, and once stabilized, they are stable.

Qtractor is a good example of how to correctly update a program.


Maybe the comparison is not very fair, but in this program it is characterized by its constant updates and has been improving over time.

And finally.

I suppose that this subject has been mentioned or even debated in another occasion; Perhaps this thread is closed, but this topic can not be ignored, it must be taken into account, and it must be the object of conversation, since all the current development of LMMS and its rapid growth depends on this simple problem, and if not is solved on time, many users would be disappointed with this beautiful application. regards

[M374LX]

Totally agreed. 👍

[musikBear]

@Gabrielxd195
Every word you wrote is my exact thoughts!

[Gabrielxd195]

I love this program, but I'm worried about the path the developers have been taking. Currently I can not use the rc8 version in debian due to jack problems # 4846. now many debian users should wait for stable 1.2. If it were otherwise, this could be solved quickly with a maintenance update. regards

[tresf]

I can not use the rc8 version in debian due to jack problems #4846

Let's not throw the baby out with the bathwater. #4846 is a strange regression which needs investigation (I'll start that right now).

Our release cycle will be faster once 1.2.0 is released, we'll move 1.2.0 to stable, then move the beta button to a nightly release cycle. Eventually, master will be a good, stable branch, but we have no more people helping than we did when we started the stable release years ago (and worse, most have left).

• Qt5 was a huge hit on us as well. We had to retire Qt4 and it took a long time to do this properly. See Switching to Qt5 #2611 one of which was Add all the Qt5 Linux VST implementations #3786.
• We didn't even have AppImages when stable-1.2 started but we made it a point to add it, which was also a huge undertaking. Add AppImage support to Linux builds #3688
• Our last lead developer left us with a bad memory manager. Poor Memory Manager performance #3865

If someone wants to jump in and help maintain the project, do it. Please stop complaining about a volunteer run program not being timely.

In regards to regressions in the AppImage, feel free to ping me on Discord. I've unsubscribed from the bug tracker because it was taking up too much of my life.

[tresf]

Closing to clean up the tracker. Feel free to continue your comments below.

[Gabrielxd195]

Closing to clean up the tracker. Feel free to continue your comments below.

You say it's to clean the tracker. I suppose it's to maintain order. but I suggest that this topic can not be overlooked should be the subject of conversation, because after the release of stable 1.2 will make it necessary to take action and change the release model, to accelerate the development of LMMS. regards

[tresf]

@Gabrielxd195 currently the developers are in charge of the release model. If you'd like to jump on that team and move that along quicker, you know how to reach us. None of this conversation is new, we just have lives in addition to LMMS and LMMS comes second. ❤️

There's going to be a mass pruning of bug reports and I'd like to invite anyone capable of volunteering and helping. These bug reports are going to be ones that clutter our tracker and make it hard to track in-progress features and serious bugs.

For example, losing JACK (#4846, now fixed) in our RC8 is a big problem, but as a maintainer of the AppImage, I wasn't made aware of this -- largely due to the fact that our issue tracker has become a wishlist with no quality standards forcing me to unsubscribe from notifications.

The master/nightly proposal has been on the table for a long time, so it's not something that needs an active discussion. Technically, it's an lmms/lmms.io discussion because it's a change to our website code.