Lmms: Next LMMS Release and Roadmap

[Anonymouqs]

I'm going to start making an LMMS roadmap on the wiki. Like in GIMP What features are we going to have in the release? And when are we going to do that release?

I heard that if you know what your outcomes are, your chances of success increase a thousand-fold.

This issue is made to come to a conclusion on what we are doing in the future. Please do not get this off topic.

[tresf]

Is this in response to https://github.com/LMMS/lmms/issues/4182#issuecomment-368941338? Milestoning marketing efforts and trying to milestone the software features aren't the same. Let's not bite off more than we can chew here. :)

[Anonymouqs]

This is just to document a roadmap. Not advertising, but I guess it could be used for that as well. Maybe it's too early to do a roadmap on the wiki.

[tresf]

@Anonymouqs GitHub has some built-in triaging and project management utilities as well as milestones. Maintaining a constantly changing section of the wiki seems to be a bit of an overkill when the functionality is built-into the product, don't you think? https://help.github.com/articles/about-project-boards/.

Furthermore, you may want to take the leap to Trello. We can sponsor power-ups if needed for proper execution.

[fundamental]

@tresf IMO github issue tracking of milestones and a wiki summary can have very different audiences. Consider "Calf is at v1.2.3, please update to v.2.3.4 for more cowbell" vs. "Update builtin plugins to external versions".

One of them is for individuals familiar with the goings on within LMMS and the other can be for users to take a glance at to know the direction of the project without the details. The former is an internal management tool while the latter can be (if targeted) an external marketing tool.

[tresf]

The former is an internal management tool while the latter can be (if targeted) an external marketing tool.

It was just a recommendation, and one in the direction of progress. Trello can handle high-level milestones, as can GitHub.

My primary concern is I specifically requested that @Anonymouqs milestoned some of his marketing ideas and now he's promising to make a futuremap. It's not what we discussed and a quick chat on Discord would have avoided yet another futuremap post.

Here's our 4-year-old futuremap. It's probably a good place to start.
Some of the items we've made progress on since it was written. Many we have not. https://github.com/LMMS/lmms/issues/908

[Anonymouqs]

I'll put the wiki roadmap later down the road. I'll start getting a step-by-step marketing plan ready instead.

[musikBear]

my ½ bend € on this:
Frequent releases, at least bi-annual, Like june 1. and dec 1. -It would be a day to look forward too for all users!
These bi-annuals should be with a limited number of new features, i would say 5 would be appropriate. -And, yes i mean _hold back_ finished new features for next release!
Bug-solving releases should come out asap, after solvage, and not include new features.
Road-map should be internal, not shared with community, because the nature of lmms is that noone ever know if something is going to happen, and when. A public road-map, will just lead to users 'grumpeling' over broken 'promises' .

[Anonymouqs]

A public road-map, will just lead to users 'grumpeling' over broken 'promises' .

What about just an "approved features list" showing which ones are being worked on at the moment?

[tresf]

I'm going to start making an LMMS roadmap on the wiki.

@BaraMGB mentioned this on Discord (https://lmms.io/chat). Can you please create this and close the bug report?

[Anonymouqs]

@tresf Since the wiki is going to be closed, I'm going to delay the roadmap until the GitBook version is up so I can focus on Stable-1.2's release.

[tresf]

@tresf Since the wiki is going to be closed, I'm going to delay the roadmap until the GitBook version is up so I can focus on Stable-1.2's release.

Not the LMMS wiki. This is a developer roadmap, it belongs here. We can clone it to the website eventually, but the tasks should have nothing to do with the wiki. The wiki is a huge, endless task.

In regards to you mentioning the "closing of the wiki", please take careful consideration to make bold statement which may come as alarming to those that don't know which context. I'll explain for you... Something we've discussed on Discord is an effort to migrate the current wiki to GitBook.

To be absolutely clear... No one's started the GitBook migration, no one's started the milestone document.

BTW, the empty gitbook lives here, for anyone interested in starting the rewrite. https://www.gitbook.com/@lmms

[dvzrv]

Whatever you choose to do, I would like to recommend the following from a package maintainer point of view (and only adressing release cycles, not documentation in my comment): release soon, release often.
The last stable release is more than three (!) years ago. Meanwhile qt4 has gone EOL and downstreams, such as Arch (for which I do the package now) will deprecate it very soon, meaning lmms will be dropped.
As the -RC versions break semver, I am unable to build the current release candidates as the new current version, even if I wanted to.
Additionally, such extreme release cycles put a lot of work on the maintainers, as they have to patch more than actually deliver.

Certainly, it doesn't help to put in more and more recent (and even arbitrary, e.g. #4534) issues, as this is a can of worms. I understand, that you would like to have the most stable outcome possible, but I have the feeling this is very contra-productive.
I would rather focus on more frequent patch level releases, instead of misusing the minor versions as major versions. Ideally, that way more downstream help can be sourced (as people actually have a stable version installed, that is current and are not reporting bugs for bizarre things that break, because lmms' dependencies have been changed/updated).

That all being said, please don't get me wrong: I'd be very happy to ship the newest lmms versions, if there are any! Please make it happen and keep up the great work! :-)

[tresf]

Certainly, it doesn't help to put in more and more recent (and even arbitrary, e.g. #4534) issues, as this is a can of worms. I understand, that you would like to have the most stable outcome possible, but I have the feeling this is very contra-productive.

4534 would never be a showstopper, so that's a bad example.

I would rather focus on more frequent patch level releases, instead of misusing the minor versions as major versions. Ideally, that way more downstream help can be sourced (as people actually have a stable version installed, that is current and are not reporting bugs for bizarre things that break, because lmms' dependencies have been changed/updated).

We're ready for this on master, actually. We'll be doing nightlies once 1.2.0 is released, which will bump 1.1.3 off of our downloads page, we've just suffered some pretty serious developer loss over the years.

qt4 has gone EOL and downstreams, such as Arch (for which I do the package now) will deprecate it very soon

Qt5 is one major delay to the next stable release. Please see https://github.com/LMMS/lmms/issues/2611. Although from an outsider, "Switch to Qt5 or you'll be unsupported" sounds like a noble, sane thing to say, the reality is that our users need VST support and just the sub window implementation was a pretty big endeavor #3786, so it's not a delay tactic. :D Take a look at this serious regression with how Qt5 parses floats https://github.com/LMMS/lmms/issues/4241.

Furthemore, we've provided AppImages for our beta versions since December and they're tested and working on Arch as well as FatDog, Fedora, PCLinuxOS, ChromeOS and a dozen others including some BSD versions so availability has actually improved albeit not (yet) in alignment with rolling-release OSs.

I'd be very happy to ship the newest lmms versions, if there are any! Please make it happen and keep up the great work! :-)

The stable-1.2 branch is what you should be shipping, really. Once that's out the door, master will be our rolling release cycle.

[dvzrv]

we've just suffered some pretty serious developer loss over the years.

So I've heard at this year's LAC! That's pretty bad, indeed.
This doesn't change much about the release cycle being too long (with too many release candidates and not enough minor and or patch level versions in between: none). I hope you can work this out in the future.

Furthemore, we've provided AppImages for our beta versions since December and they're tested and working on Arch as well as FatDog, Fedora, PCLinuxOS, ChromeOS and a dozen others including some BSD versions so availability has actually improved albeit not (yet) in alignment with rolling-release OSs.

That's exciting news! However, it doesn't help my situation (as it's also nothing I can ship).

The stable-1.2 branch is what you should be shipping, really.

I can't just ship HEAD ;-)
For a package in [community] I require a properly tagged version, that I can build. The release candidates sadly won't do, as the -RC part breaks semver and that would then not pick up 1.2.0 properly, once it gets released.

All in all, I'm really looking forward to stable 1.2.0 and hope you can release it soon!

[tresf]

This doesn't change much about the release cycle being too long (with too many release candidates and not enough minor and or patch level versions in between: none). I hope you can work this out in the future.

We've already said we will with master. Please don't pick on the major/minor stuff either, that's bikeshedding in the grand scheme of things. :D

For a package in [community] I require a properly tagged version, that I can build. The release candidates sadly won't do, as the -RC part breaks semver and that would then not pick up 1.2.0 properly, once it gets released.

No one said to ship HEAD. It is tagged. No, it doesn't break semver. It's slightly non-standard (should be -RC.6 with a dot between the RC and the 6, technically), but it doesn't break semver per: https://semver.org/spec/v2.0.0-rc.2.html. If it breaks semver for you, your library is broken.

[tresf]

And if I'm wrong about the semver stuff, blame @lukas-w per https://github.com/LMMS/lmms/issues/3594#issuecomment-317194762. 🤐

[dvzrv]

We've already said we will with master. Please don't pick on the major/minor stuff either, that's bikeshedding in the grand scheme of things. :D

I'm not trying to play the blame game here ;-)
It's just something I see and I feel has obvious pitfalls.

If it breaks semver for you, your library is broken.

Well, it breaks semver for me, if I would try to ship an -RC version (because I would have to replace the - with a . to make that happen). The - is reserved by Arch's packaging standards for an update to the package script (PKGBUILD). Therefore, shipping an -RC version would always lead to something like major.minor.patch.release.
This makes it impossible for me to ship any of the -RC versions without getting in conflict with the upcoming major.minor.patch release. That has nothing to do with a library being broken, but is by design (we ship the latest stable, not the latest whatever - at least in the main repositories). :)
Using release candidates is all no problem (I just can't ship them). It becomes a problem, if there are only release candidates and no stable releases! ;-)

[tresf]

We used to do 1.1.990 and computers were happy but users got confused.

I can't fathom why Arch hates dashes, but if the delayed release causes issues, we have a way to overridde internal build info through cmake.

The downside to this unorthodox back versioning approach is it risks the chance of projects not being upgraded properly, so probably best to wait. 😕

[tresf]

Ok, vercmp on arch clearly allows RC builds. I think you just need to strip the dash (NOT replace it with a dot). Per https://jlk.fjfi.cvut.cz/arch/manpages/man/vercmp.8.

Specifically the part that says:

// Version comparison operates as follows:

// Alphanumeric:
1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1

// Numeric:
1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0

[dvzrv]

Hmm, yeah, you're right. 1.2.0rc6 might actually work (is probably frowned upon a little, but it's for the good cause of demoting qt4! :) )!
I'll try that tomorrow! But I think internally it will get a little weird during packaging. Guess I'll have to sed this line before building as well (with which we're at the downstream hacking again ;-) ).

However, this shouldn't keep you from releasing more often! ;-)

Thanks for the hint!

[tresf]

@dvzrv alternately, after the build you could:

lmms --version |head -n 1 |cut -d' ' -f2 |sed -e 's/-//g'
# outputs: "1.2.0rc6"

# explanation:
#   lmms --version  :   echos multiple lines of build information
#   head -n1        :   grabs first line (e.g. "LMMS 1.2.0-rc6")
#   cut -d' ' -f2   :   splits on space character, grab second element (e.g. "1.2.0-rc6")
#   sed -e 's/-//g' :   replace dashes with nothing (e.g. "1.2.0rc6")

I would consider this approach slightly more reliable as the command line is less likely to change drastically over time whereas CMakeLists.txt has changed considerably over the years.

[tresf]

I'm going to start making an LMMS roadmap

Apparently not. Closing, abandoned.

[tresf]

Per above conversation, Contributors page published: https://github.com/LMMS/lmms/wiki/Project-Maintainers.

The rest of this is an abandoned and mostly off-topic conversation. Closing.

[tresf]

Oh... in regards to a futuremap, we don't really have one still, but @DouglasDGI and I are building a workflow wishlist here: https://github.com/LMMS/lmms/issues/4877

We need help cleaning up the tracker. Volunteers welcome, instructions are at the top of the bug report!