[Interest] [Development] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi,

On 12.06.2020 02:17, Scott Bloom wrote:
> One thing that I probably missed in this thread, though I have been reading it with quite a lot of interest.
> 
> Why is Win7 being dropped?  I (my company) has gotten burned pretty hard by the dropping of CentOS 6, similar reasons listed for win7..
> 
> Is win 7 being dropped because the Visual Studio versions being supported, can no longer target Win7?

 From the R&D perspective the main reason for dropping Windows 7 is 
"resources". We just do not have the manpower/processing power to 
support every configuration out there. Some examples for the decreased 
maintenance effort are shown in initial mail, the mail that was sent 
back in March last year and inside the bug report.

That having been said this discussion wasn't done by R&D alone. Other 
departments like product management were involved and according to the 
available customer data dropping support for Windows 7 should be "ok". 
Of course dropping support for an OS is never ideal but weighing up pros 
and cons we came to the conclusion that Qt6 is the right time to do this 
cut.

Of course not everyone will agree on this conclusion, but that's the way 
the decision was made.

BR, Olli

> 
> Our customers (multi-national, semiconductor companies) often will not change OS's the moment a chip design is started.  They "may" patch security, but often, they simply limit access to the outside world so connectivity security is not really their concern. The applications aren’t "online" they are usually command line drive, with UI interfaces for debugging the issues found.
> 
> We still had to support CentOS 5 until about 2 years ago, when our customer finally was able to drop it in their process.
> 
> For CentOS 6, I understand it was for enhancements in the Qt functionality.  However, I think it’s a major mistake for any MAJOR version to drop an OS.  Adding is fine, but dropping shouldn’t happen.
> 
> If I were king for a day, if its "mostly source compatible" then the OS (and compilers) should still be supported.  In this case, unless it’s a patch required on the compiler (to fix a bug) I should be able to build Qt 5.X even if it requires a dev-tools patch.  Same for Win7 and VS 2013.
>   
> Moving from Qt5 to 6, I am ok with dropping Win7 and/or CentOS 6.  I disagree with Roland here.  Yes, it would be "better", if I could easily build against the latest version of Qt, and build it for an ancient version of any particular OS. But in order to do that, I would expect the configuration options would go insane.  Any item that doesn’t build for that OS (it might not have that functionality that code was added for a newer version of the OS) would have to be ifdef'ed out via configuration. It’s a possible but expensive solution.
> 
> However, I do think, and from a commercial license holder POV (which my current company is), in general it is really painful when an OS is dropped from one LTS to another.  We are actually hitting that issue right now.  We want to move to 5.15, but have a 20 million + a year, contract tied to CentOS 6.  We really can't even consider  dropping centos 6, instead we have to port Qt to CentOS, or stay on the last version of Qt that built on it.  It’s a really crappy position to be in.
> 
> Telling a customer such as us, for Qt 6, you cant build for CentOS 6, would mean, we would simply stay on the Qt 5 tree even longer, and likely pay for extended support until we could move off of CentOS 6.  But we know of bugs, that directly affect us that have been fixed in newer versions of Qt, and we wind up having to back patch them to the Qt we are using, so we can still support our OSes
> 
> Scott
> 
> -----Original Message-----
> From: Interest [mailto:interest-bounces at qt-project.org] On Behalf Of Roland Hughes
> Sent: Thursday, June 11, 2020 4:57 PM
> To: Sérgio Martins <iamsergio at gmail.com>
> Cc: Qt Project <interest at qt-project.org>
> Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6
> 
> 
> On 6/11/20 6:07 PM, Sérgio Martins wrote:
>> On Thu, Jun 11, 2020 at 9:51 PM Roland Hughes
>> <roland at logikalsolutions.com> wrote:
>>>
>>> On 6/11/20 1:47 PM, Michael Jackson wrote:
>>>> Windows 7 is EOL. Period. If it costs you, as a developer, additional money to support an EOL'ed, unsupported version of an operating system then you will need to pass that onto the customer. By still supporting Windows 7 we, as developers, are just enabling those customers to keep from updating. There are very few real reasons*not*  to update to at least Windows 8. At some point the customer needs to understand that they are not going to get any new features. They current piece of software will keep working (Assuming a perpetual license) but nothing new will be supported. I've had requests to back port our software to CentOS 6 and once you explain the cost to them for us to maintain all the extra development hardware, extra engineering to develop codes that are not supported on the old compilers, it becomes cost prohibitive to maintain those versions.
>>> Personally I don't think anyone should be running a virus known as
>>> Windows on any computer.
>>> There are major corporations still running Windows XP, let alone 7,
>>> because they have critical systems written and running on that OS.
>> They can continue to. And why would critical systems be ported to Qt 6 ?
> 
> Not ported, added to.
> 
> 
>>
>>
>>> The
>>> tool or whatever cannot port forward or costs massive amounts of
>>> money to bring forward. Just today someone told me about one of GM's
>>> factories in Europe is run by a highly customized "canned" factory
>>> control system written in VB5. When people show up to the factory, it
>>> makes vehicles every day.
>>>
>>> You can't have rolling upgrades on critical systems, you just can't.
>> Then why would you want to port that to Qt 6 ?
> Not ported to, added to.
>>
>>
>>> Upgrading is a multi-million dollar cost adding nothing to the bottom
>>> line. They really don't care if a third party developer's life is any
>>> easier, that developer isn't on the payroll and they have an
>>> auto-renewing can only be cancelled for non-payment support contract.
>>>
>>> Windows 7 is EOL in marketing only.
>> Just like Qt 3, 4 and 5 will be used for many years.
>>
>>> I'm willing to bet CAT is still using WinCE. They were as of less
>>> than a year ago because a contract hit my inbox.
>> Yes CAT for sure won't be ported to Qt 6. Why do you even mention it
>> on a thread about running Qt6 on Win7 ?
> Because there seems to be a continuing focus here to only care about what Apple is shipping tomorrow and what Best Buy is selling today.
> That's not how it works in embedded systems.
>>
>>
>>> I don't know how, but Agco has their own version of DOS and is
>>> somehow using Qt.
>> And they can continue to, regardless of the outcome of this thread.
> No, they can't. They won't be able to do enhancements.
>>
>>
>>> As I said, I don't personally care about Windows. If Qt drops support
>>> for Windows 7 going forward it will simply shove a big chunk of
>>> current users (who aren't using QML and JavaScript) to CopperSpice
>>> because it claims to still be supporting Windows via MinGW all the
>>> way back to Windows Vista.
>>>
>>> https://www.copperspice.com/docs/cs_overview/supported-platforms.html
>>>
>>> You cannot force customers to "upgrade" but you can force them to leave.
>> So their systems are too critical to update software but a port to
>> CopperSpice is fine ?
>>
>> All the examples you gave don't care about Qt 6, in fact many of them
>> don't even run on Qt > 5.6, which dropped support for WinCE and XP.
>> And that's OK, it's the software lifecycle.
> 
> Not port, add to.
> 
> You are still thinking in the home hobby x86 frame of mind. That's not how a line works.
> 
> At some point on an assembly line you have a local control system.
> 
> Today they are making the GMC Sierra 2500 and at this point in the line there is a welder hooked up. The worker loads the control program that runs the bead on the left side of the truck welding the front cab post to the frame then engages the rear cab post weld as the line crawls.
> 
> Next week that same spot on the line has a robotic grinder hooked up.
> The worker loads the grinder control program for the vehicle model being made that week.
> 
> For the 2021 model year, a shiny new type of machine needs to be at that spot in the line. It needs a shiny new control program THAT MUST RUN ON THAT BOX. Yeah, you can find people that still know the version that runs on there. How about for the 2028 model year?
> 
> There is a medical device that Harman emails/calls about seems like every 18-36 months using Qt 3.x and OS/2. The problem for them isn't maintaining the equipment and development tools, it's finding someone that doesn't have to start from scratch learning Qt 3.x. They can get by with a shorter trial and testing period if say, Qt 6 still compiled on
> OS/2 because if you aren't changing out the OS there are different rules. A full new product clinical trial would cost millions of dollars.
> It's cheaper to play people like me off against one another trying to find someone charging less than $180/hr knowing full well you are probably going to pay $225/hr for on-site work than it is to do an OS and full tool set swap because now you have to go through the full "new product" clinical trial (usually.)
> 
> So no. I'm not saying PORT. I'm saying they would switch new development (and any support/royalty/licensing) contracts to a similar tool set that still supported the platform.
> 
> If Qt is only chasing the last version shipped then it can kiss any hope of royalties goodbye. What incentive is there to sign up and pay royalties when the embedded system OS they used gets dropped like yesterday's newspaper?
> 
> I keep trying to explain it but it falls on deaf ears. Big business; real systems at real companies; need 15-30 year (not month, year) support cycles.
> 
> But hey! If Qt Company doesn't collect one red cent from customers because developers keep dropping the very platforms that just might pay big support contracts, that's OK, it's the software lifecycle.
> 
> 
>