Would be helpful if @DomClark and @PhysSong drop their tidbits here.

What dev resources is it weighing down? If this is specific to the Qt 6 migration, then we simply only add 64-bit Qt 6 jobs. I'm not sure that we gain anything by removing the existing 32-bit Qt 5 jobs.

This argument seems legit too. We'll keep Qt6 64 bit only and use Qt5 for both 32 and 64 bit builds.

@DomClark

I'm not sure that we gain anything by removing the existing 32-bit Qt 5 jobs

It has been said, but I'll reiterate: it's basically only about having 64-bit Linux doing a MinGW 32-bit Windows build (and MSVC x86, if you count the pipelines for the dev branch). Nothing else would be dropped AFAIU/K.

What dev resources is it weighing down?

Time and effort of anyone wanting to maintain and/or update the CI pipelines or numerous dependencies we don't have up-to-date ATM, for one. LMMS is terribly outdated in many areas right now, and reducing the tech debt would require going through that one way or another. It's been 4 years since last stable release. The roadmap for 1.3.0 is yet still far from being finished IMVHO.

I'm biased on this one, because in my day job (corporate setting) a lot of my effort goes into maintenance of things that nobody really needs. 32-bit Windows builds of a normal software app are exactly this in my book. 64-bit Windows are available since Windows XP in 2003. We're talking about more than 20 years ago. Vendors which didn't stop 32-bit support are doing so right now. Ubuntu stopped AFAIR at 18.04. for Windows it's planned in 2025 I believe. Same with drivers and everything else. Of course, you will be still able to run 32-bit apps (with ~3GiB physical RAM available, enough for 2 or 3 feature-rich VSTis chuckle)... but why should we additionally build 32-bit apps for 64-bit systems? I see no point.

Like I said, I've already seen build problems for 32-bit MinGW when trying to update. That's the only 32-bit platform that is currently supported as first-class citizen on LMMS (i.e. is supported and was supported by at least one stable version). It's also, arguably, the least used.

If this is specific to the Qt 6 migration, then we simply only add 64-bit Qt 6 jobs.

It's not specific to Qt 6 migration, it's related to it though. However, as a side note, I'd say that having both Qt 5 and Qt 6 in parallel OTOH seems like a great way to make future UI work exceedingly tedious, in all respects (bugfixing, adding new features, you name it).

What dev resources is it weighing down? If this is specific to the Qt 6 migration, then we simply only add 64-bit Qt 6 jobs. I'm not sure that we gain anything by removing the existing 32-bit Qt 5 jobs.

I agree, it's not weighing us down; I think @Rossmaxx took some generous liberties of inference from this #6614 (comment) or perhaps this #6614 (comment).

That said, I do think 32-bit support should be removed from the downloads area moving forward. I do not believe 32-bit builds have a reasonable purpose there. And over time, I believe ARM64 downloads will be more helpful to users.

I have opened LMMS/lmms.io#389 as a first step.

I have opened LMMS/lmms.io#389 as a first step.

The title of this PR is:

Drop 32 bit support from CI.

However, the proposed solution at LMMS/lmms.io#389 is to remove them from showing. This step seems unnecessary as it'll happen automatically once we stop building them. I've left the same sentiments over there, since some people may not read both bug trackers.

#7619 is the proper fix. Took a bit long but here I am.

Some additional context... If you look at https://api.github.com/repos/lmms/lmms/releases, you can see exactly how often 32-bit Windows downloads vs. 64-bit Windows downloads are being used. The rates are much higher than I would have expected:

Alpha:

Stable:

... I'm not sure why the increasing rate (due to historical support of 32-bit OSs, I would expect stable releases to have higher 32-bit download rates).

One possible cause is that the alpha releases may be suffering performance or stability issues that users are more likely to try the 32-bit installer to remedy, since -- in 2024 on Windows -- 64-bit OSs can still run 32-bit installers just fine.

Regardless, these figures do shed some additional credibility to @Rossmaxx's recommendation to place a warning on the downloads once removed, which is mentioned here:

• Add warning for missing 32 bit downloads for nightly lmms.io#389

Side-note: @Rossmaxx please rename the above lmms.io PR to more accurately reflect what it's doing.

Some additional context... If you look at https://api.github.com/repos/lmms/lmms/releases, you can see exactly how often 32-bit Windows downloads vs. 64-bit Windows downloads are being used. The rates are much higher than I would have expected:

The reason might be dead simple. Many people don't know they can or should use 64-bit one, they just click "32-bit" because it worked for them in the past years... people often just click the first download that's "good enough" for them, and don't think about it later on if it works.

Mind me, I've downloaded 32-bit binaries a lot of times myself by mistake, and I am well aware which one I wanted to download. You might be surprised how the 64-bit version download counter will increase after disabling 32-bit download :D

This seems more plausible if you take into account that 32-bit LMMS still works just fine on 64-bit machines AFAIK :)

The reason might be dead simple. Many people don't know they can or should use 64-bit one, they just click "32-bit" because it worked for them in the past years...

Yeah, occam's razor, but the upward trend is still alarming. I agree, time will tell. The more important part I think is that @Rossmaxx's push for communication -- at least in the nightly downloads area -- is a good idea.

Side-note: @Rossmaxx please rename the above lmms.io PR to more accurately reflect what it's doing.

I thought i should have done that. Forgot about it. On it.