Drop support for Ubuntu 16.04 Xenial

[uklotzde]

Replacement for PR #2581

• Require GCC 7 with decent C++17 support
• Require Qt 5.9 LTS and remove all obsolete workarounds
• Remove std::optional hacks for GCC 4/5/6
• Add qDebug() support for std::optional

[daschuer]

I was afraid if this PR, I originally want to save you from the work doing it. This has no benefit, just breaks Xenial support.

We have no technical need that rectifies this change now.

[daschuer]

Let's keep this PR open until the final 2.2 was released or there is a pressing need to drop Xenial support.

[uklotzde]

This does not affect the 2.2 release at all.

All my future work will exclude Xenial support. I have a technical need.

[Holzhaus]

Let's keep this PR open until the final 2.2 was released or there is a pressing need to drop Xenial support.

Will 2.2.4 be the final 2.2 release?

[Be-ing]

@daschuer I don't think it's fair to ask every other developer to keep going out of their way to support old software because you keep using a 4 year old OS.

[daschuer]

@Be-ing you probably have not followed our discussion in #2581

It is just that my development machine is running Xenial, to be able to support the Mixxx 2.2 branch. Normally this should have been legacy since a year, but that's another story.

I am happy with updating the CI, to let not every developer stumble over this legacy.
I will care for keeping compatibility myself.

But if we merge this here, it artificially forces me to upgrade to Bionic.

No Core team developer will be able to support Xenial issue than. At least I am not willing to do that without a setup by the hand.

[daschuer]

Will 2.2.4 be the final 2.2 release?

I would prefere doing this. Do one last 2.2 short before 2.3 and than drop the support.

[uklotzde]

I will no longer support this old development environment. Feel free to reject my contributions.

[ywwg]

I would prefere doing this. Do one last 2.2 short before 2.3 and than drop the support.

merging this PR into master wouldn't affect the 2.2 branch, would it? So if the plan is to do another 2.2 release and drop support for 2.3, this PR seems ok to merge to master.

[uklotzde]

These changes do in no way affect the 2.2 branch. But master will no longer compile on Ubuntu 16.04 Xenial.

[ywwg]

Can we make it so that we only compile 2.2 for xenial, not master?

[Be-ing]

That's what #2581 does.

[ywwg]

ok then, @daschuer , I think what you want is what will happen? 2.2 will still be built with xenial support, but master/2.3 will move on. Is that ok?

[daschuer]

Yes, let's merge #2581, but postpone the changes here. I will take care that my Xenial still compiles with 2.3. until 2.2.4 is released.

[uklotzde]

Daniel would no longer be able to build master on his local development machine. That's the only inconvenience. For testing 2.2 on Ubuntu 16.04 Xenial I recommend using a VM.

[uklotzde]

I have a VM for 18.04 and preparing one for 16.04. Just to be able to understand reported issues.

[uklotzde]

Merging #2581 will not prevent changes that are not backwards compatible with Ubuntu 16.04 Xenial. We should apply either none both. Therefore I will close #2581.

[ywwg]

Yes, let's merge #2581, but postpone the changes here. I will take care that my Xenial still compiles with 2.3. until 2.2.4 is released.

how long are you asking to postpone? Until 2.2.4 is released? Do we have an estimate of that? I think people might be ok with holding off if we have a better understanding of the schedule.

[daschuer]

Yes, exactly. For my understanding this will we close connected to the 2.3 release.
This will done once we are able to mass replace default orange as cue color.

Actually I can't understand why dropping Xenial support also means to break compiling it. If one likes to compile it for some reasons it feel wrong to revert the work to allow it.

[uklotzde]

I want to make some progress instead of being blocked needlessly.

[daschuer]

You did not yet explain, why these workarounds block you.
I want also make progress. So let's finalize the hot cue color topic and release 2.3 instead of arguing about needless breaking Xenial.

[Be-ing]

Merging #2581 will not prevent changes that are not backwards compatible with Ubuntu 16.04 Xenial. We should apply either none both. Therefore I will close #2581.

I don't understand why these must be coupled. We can switch the CI to Ubuntu 18.04 without merging this. It would then be up to @daschuer to keep master/2.3 building on Ubuntu 16.04. I am okay with that compromise as long as @daschuer does not ask anyone to change anything in future PRs or delay merging PRs just for the sake of keeping the build working on Ubuntu 16.04.

[uklotzde]

As soon as the CI changes have been merged those become the reference. Then no complaints that the code doesn't compile on someones local machine could be accepted. And this will happen very soon, because I already have code that will cause exactly such a situation. Switching "just" the CI and leaving the code unchanged gives a false impression.

It's a matter of priorities. If the project decides to stick to anachronistic tools and technologies then be it so. This strategy doesn't align with my expectations.

[Be-ing]

this will happen very soon, because I already have code that will cause exactly such a situation

Okay, it wasn't clear from the prior discussion on this or #2581. In that case, I agree, let's merge both this and #2581.

But if we merge this here, it artificially forces me to upgrade to Bionic.

There is nothing artificial about it if @uklotzde has code he wants to merge making use of features unavailable in Ubuntu 16.04. You are artificially asking everyone else to keep working around old software. Every other contributor has found time to update their OS in the past 4 years. I think it is unfair to demand everyone else do extra work because you haven't done this. Ubuntu 18.04 has been out so long now that the next LTS release is only a month away.

[daschuer]

this will happen very soon, because I already have code that will cause exactly such a situation

Please point us to that code.

Since the beginning of this discussion I support to remove Xenial from our CI.
So let's do it.

But please delay the removement of the Xenial workarounds after the 2.3 release.
I wi take care of this. For no maintenance burden for anyone else.

@Be-ing:

You are artificially asking everyone else to keep working around old software.

That's not true. Please stop blaming me for this.

[Holzhaus]

Let me try to pour some oil on troubled waters. @daschuer is using Xenial to make sure that Mixxx 2.2 still builds on that OS, not because he's lazy. Because he obviously uses the same machine for 2.2 and 2.3 development, he won't be able to do that after this has been merged.

I agree with @uklotzde that we shouldn't require to work around xenial issues for 2.3. This PR does only remove Xenial support, but doesn't add any new features or fixes, so I guess it's reasonable to postpone merging this until we broke Xenial support anyway by merging a PR that adds or fixes something in Mixxx.

So @uklotzde can just ignore Xenial support from now on. As soon as master becomes incompatible with Xenial, let's merge this PR. @daschuer will need to update his dev machine at that point anyway. The CI changes can be merged immediately AFAIC.