Merge remote-tracking branch 'origin/5.12.4' into 5.12

Change-Id: Iaa39bce686a133006a61ccfcc82aea5f95571d7c

2 files changed, 72 insertions, 1 deletions

diff --git a/.qmake.conf b/.qmake.conf
index 00971a0..2472de2 100644
--- a/.qmake.conf
+++ b/.qmake.conf
@@ -1,6 +1,6 @@
 load(qt_build_config)
 CONFIG += qt_example_installs
 
-MODULE_VERSION = 5.12.3
+MODULE_VERSION = 5.12.4
 
 QTRO_SOURCE_TREE = $$PWD
diff --git a/dist/changes-5.12.4 b/dist/changes-5.12.4
new file mode 100644
index 0000000..e415add
--- /dev/null
+++ b/dist/changes-5.12.4
@@ -0,0 +1,71 @@
+Qt 5.12.4 is a bug-fix release. It maintains both forward and backward
+compatibility (source and binary) with Qt 5.12.0 through 5.12.3 under most
+conditions.  There may be exceptions if you are using Qt Remote Objects
+between proesses or devices running different versions Qt.  The different
+versions of Qt must be running compatible versions of QtRO's protocol.
+
+Changes to the Qt Remote Objects protocol are documented online:
+
+https://doc.qt.io/qt-5/qtremoteobjects-compatibility.html
+
+The QtRO protocol has been updated in Qt 5.12.4 and Qt 5.13.0 to 1.3.
+
+Background:  Qt's QueuedConnections work by copying signal parameters so
+the copy can be held and then later processed in another threads
+eventloop, allowing the original data to be changed in the originating
+thread.
+
+Qt Remote Objects leverages this capability and sends that data from a
+QObject in one process to a QObject in another.  There is a specific
+protocol for this, as both sides need to interpret what is sent the
+same way.  For example, there are Invoke and PropertyChanged packets
+exchanged.  In addition to this, both sides need to know how to encode and
+decode all types shared.  This type awareness is easy to ensure if the
+repc compiler is used to generate the headers for all sides.
+
+However, there are use cases where this isn't possible.  In these cases
+QtRO will send the type (metaobject) information as well, allowing the
+receiving side to generate the required type information at runtime for
+certain types (PODs and enumerations).
+
+There were issues found in this type serialization code that required a
+change to the protocol.  There are a number of commits going into both
+Qt 5.13.0 and Qt 5.12.4 with fixes.  This means that you will not be able
+to use Qt Remote Objects on a device using Qt 5.12.3 or earlier and
+communicate to another device using Qt 5.12.4/5.13.0.
+
+For more details, refer to the online documentation included in this
+distribution. The documentation is also available online:
+
+https://doc.qt.io/qt-5/index.html
+
+The Qt version 5.12 series is binary compatible with the 5.11.x series.
+Applications compiled for 5.11 will continue to run with 5.12 as long as
+the protocol change noted above is taken into account.
+
+****************************************************************************
+*                        Important Behavior Changes                        *
+****************************************************************************
+
+ - Qt Remote Objects uses an internal protocol to pass data between
+   processes and/or devices. The same protocol version needs to be used on
+   all sides. The version was bumped from 1.2 to 1.3 in this release,
+   fixing potential crashes (see QTBUG-75017). If there is a mismatch, the
+   connecting node will output a warning and the host node will not send
+   any data.
+
+Some of the changes listed in this file include issue tracking numbers
+corresponding to tasks in the Qt Bug Tracker:
+
+https://bugreports.qt.io/
+
+The following fixes were part of the above protocol change and are in
+5.12.4 and 5.13.0.
+
+Each of these identifiers can be entered in the bug tracker to obtain more
+information about a particular change.
+
+ - QTBUG-75017: QtRO processes can crash if type registration is incorrect
+ - QTBUG-75056: Correctly handle QVariant properties on the replica side
+ - QTBUG-74084: QT remote objects false conversion warning in case of
+   QVariant property