Qt 5.6 is for those who cannot upgrade. If you can upgrade, upgrade.
How (un)likely is it that one can remain locked into 5.6 because of dependent code that doesn't build against 5.7+? Qt's backward compatibility principle should prevent that, no?
It is extremely likely for development to remain locked to a version.
This is absolutely true. But what does it mean to keep using an outdated version in a connected system? How to ensure that the system remains secure? How to be able to bring new functionality (if / when) required by the customers? These issues may not happen for every system, but more and more will need to consider these. By being able to update the version of Qt framework regularly it becomes easier to address these issues, but of course there always are pro and cons. When creating a system, it is beneficial to make it so that it is feasible to regularly update it's components, including the Qt framework.
Please do not confuse "retail" systems with real systems. Real systems mandate stability. There are hard human consequences when anything goes wrong. Dynamic updates are incredibly bad things. For the less fatal adverse human outcome situation look back to the Northeast Blackout of 2003 https://en.wikipedia.org/wiki/Northeast_blackout_of_2003 One alarm bug caused a massive cascading failure. For medical devices _any_ change can lead to catastrophic patient outcome. The vast majority of real systems have zero direct Internet connection. If they have any network connections they are proprietary communications protocols, both historical and modern: https://en.wikipedia.org/wiki/DECnet https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture http://www-01.ibm.com/support/docview.wss?uid=swg27023930&aid=1 https://en.wikipedia.org/wiki/Token_ring http://www.computerhistory.org/revolution/networking/19/376 There are quite literally hundreds. Even CAN-BUS, widely used in the automotive and industrial world has no "real" standard. There is a published standard and Qt has some classes for it, but, you cannot write a Ford CAN-BUS application and have it work on a Chrysler or vice versa. Security by proprietary obscurity and expensive limited availability equipment. How many of you still have an official Novell Netware network card? Not one of the $29 knock offs, but the $1200 things? Security also happens via air gap. The network the systems operate on has no connection what-so-ever to the outside world. Data can be exported, but it has to be "sneaker netted" to another system. That means copied onto physical media and carried. Lastly, security happens via demarcation. Inbound connections of any type are physically not allowed. Even medical devices which communicate with patient record or remote patient monitoring systems across a "normal" network physically do not allow inbound connections of any kind. They either broadcast or periodically reach out to hard configured destinations and send data to those destinations in a proprietary (usually encrypted as well) format. New functionality is not a large concern. In the case of a patient monitor device, if the medical staff needed something other than standard temp, SPO2, BP and heart rate, they would use another device. Just like a good auto mechanic doesn't try to make one wrench fit every bolt on a vehicle, good medical staff know the one tool for one job rule. That tool can then be perfect at that job. In the case of large scale systems, such as a nationwide train routing/control system or a regional power grid control, or even a nuke plant, "new features" are a limited thing. Yes, you may add hundreds of new alarm devices which send alarm codes and/or location codes but that is a data thing, no coding changes required. Why? Because these systems employ a serious quantity of systems architecture and design BEFORE they are written. Even in a live messaging system it will be recording those messages in both a log and a database. The "active alarms" table is laid out to be written to by a "new alarm received" type process. It will have pretty much a timestamp, alarm type, alarm ID, and alarm code and 1-3 generic columns to store a float, string and int. (Some will have only the alarm ID relying on it being a unique foreign key into an alarm device table.) Once the entry is written either the database or the new alarm process which wrote it will fire a trigger telling all monitor programs to update their alarm status pages (also happens when alarms are cleared.) The status pages pulling all reference data, data format for this alarm type, location, severity, additional data columns to use and their formats, etc. Using such an architecture you can add thousands of sensor types which have thousands of alarm types without ever having to modify a line of code. A "retail" application goes into the hands of a consumer, not a user with special training. These applications tend to be bug ridden because users are accustomed to that (thank you Microsoft.) They also tend to be inefficiently written because people were in a hurry to "ship a new feature" whether anyone wanted that feature or not. The inefficiencies are of biblical proportions when scripting tools and languages are used to create the "product." "Retail" applications tend to follow a common trajectory. 1) Some idea happens 2) A bunch of code gets hacked together without any real thought given to design or architecture 3) App/program/whatever gets released into the world in a buggy state, vast majority die right here, usually as OpenSource projects perpetually carried in distros without a single line of maintenance or new development happening for over a decade. 4) If App/program/whatever attracts a user base despite its problems, creator seeks money from outside and money people demand "management." 5) "Management" announces next release of app/program/whatever will be all things to all people. Not only will it cure cancer and end world hunger, it will solve global warming and moderate weather patterns. While Wall Street drools, management seeks a buyer for the company. 6) Company buyer gets screwed. http://legalnews.com/oakland/1430462/ " During Steve Ballmer's tenure, MSFT bought 149 companies, and 121 of them have vaporized into the ether." -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
