Small master releases

[Gabrielxd195]

Please, I do not want you to think that I want to attract attention, I simply want to give my humble opinion as a common user of LMMS, about this. I do not speak English and I have never used discord.

Problems:

- Users do not have access to the master branch.

I really don't know if they've talked about this before. ordinary LMMS users do not have access to the characteristics of the master branch.

- Most lmms users do not know how to compile.

most LMMS users have no technical knowledge of programming, git, libraries, etc. I have experienced many cmake errors with QT.

- LMMS logistics errors

Believe it or not, the concept of stability and the current model of lmms releases have always been the cause of the lack of support and that users are not interested in collaborating. and because of this lmms may become obsolete. but I know it is not because I go through git and I see the great work they do to improve it.

- The stable branch only receives minor corrections and characteristics.

Despite all bug fixes, the '' stable '' branch only receives minor features over long release periods. unfortunately some users think that it is becoming obsolete, because the common user only sees the visual aspect of the program: corrections, major features and new functions. but all these things are made in master.

- Night versions of master are promised.

Since last year I have read that they will release nightly versions of the master, but since the master is a trial version, then the releases have to be constant and in short periods.

- PR take a long time to implement.

I am concerned about how pr take years to implement, and that increases developers and discourages any user who is interested in collaborating. because even if you don't believe it, the collaborators come out from among the common users. The user uses the program, analyzes it, and if it is within their possibilities, collaborates.

- Wrong concept of stability.

I read comments like: '' Master is not stable enough for an end user ''. but the same was said of 1.2 when it was still a test version; however we had 4 years using trial versions (1.2 RC) that ironically turned out to be more stable than the '' stable '' branch. In addition, any user is aware that using "trial versions" runs the risk of experiencing errors, and yet when we were in stable 1.1 we experienced many of those errors.

Maybe in the master branch, the case is different. but what would a common user do when he experiences errors in an update ?, downgrade until the error is corrected.

Suggestions:

Well, from my point of view of common user, the convenient thing would be:

- Do a master cast immediately.

My suggestion to developers do not delay and launch binaries from the master branch.
Because ordinary users are crying out for new features and the master branch has many of these features, chances are these users will spread it and attract other users.

- Close the stable branch and close the milestones.

Despite all the '' stable '' bug fixes, we are still experiencing a lot of bugs. the lack of support and collaborators makes the support of this branch unsustainable. As far as I can see, master is already stable enough for ordinary users. if you focus only on master, fixes and improvements will be faster.
 
- Analyze the pr before merging to master.

I think this could not be more clear, with all the focus on master, it would be necessary to be more preventive when merging the pr.

- Order the new features and corrections in priority order.

As there are many requests, the most convenient would be to reorganize them in priority order in each launch.

- Make small monthly or bi-monthly launches of the master branch.

To attract more users it is necessary to make small monthly or bi-monthly launches, because that gives them the confidence that their requests can be heard. I don't like to make comparisons, but qtractor keeps its users happy with its constant updates and in a single branch. we should use that launch model.

Maybe all this involves a lot of reorganization work, maybe I'm not taking into account some things that only developers know. but maintaining two branches, with few developers, with the current launch model, has become a snowball that will continue to grow over time. this is unsustainable, this cannot be ignored. My humble opinion as an end user is: close the stable 1.2 branch, reorganize the corrections and characteristics by priority, focus all the attention on the master branch, and immediately launch the binaries to the users. Cheers

[PhysSong]

It looks like a duplicate of #3347.

[Spekular]

Agreed, duplicate of 3347.