Backward compatibility with 0.6.0-rc2

[cdunn2001]

I need help with this right away. Anybody? ~cd

Hi Christopher,

I have tried to package 0.7.0 using the current tip and it seems that it
could be a backward-compatibility problem. The following log is what
symbols where defined in 0.6.0~rc2 and what are now defined. Basically,
take a look at MISSING tags:

@@ -72,7 +72,7 @@
  (c++)"Json::Value::CZString::index() const@Base" 0.6.0~rc2
  (c++)"Json::Value::CZString::isStaticString() const@Base" 0.6.0~rc2
  (c++)"Json::Value::CZString::operator<(Json::Value::CZString const&)
const@Base" 0.6.0~rc2
- (c++)"Json::Value::CZString::operator=(Json::Value::CZString
const&)@Base" 0.6.0~rc2
+#MISSING: 0.7.0~git20141116-1#
(c++)"Json::Value::CZString::operator=(Json::Value::CZString
const&)@Base" 0.6.0~rc2
  (c++)"Json::Value::CZString::operator==(Json::Value::CZString const&)
const@Base" 0.6.0~rc2
  (c++)"Json::Value::CZString::swap(Json::Value::CZString&)@Base" 0.6.0~rc2
  (c++)"Json::Value::CZString::~CZString()@Base" 0.6.0~rc2
@@ -141,7 +141,7 @@
  (c++)"Json::Value::operator!=(Json::Value const&) const@Base" 0.6.0~rc2
  (c++)"Json::Value::operator<(Json::Value const&) const@Base" 0.6.0~rc2
  (c++)"Json::Value::operator<=(Json::Value const&) const@Base" 0.6.0~rc2
- (c++)"Json::Value::operator=(Json::Value const&)@Base" 0.6.0~rc2
+#MISSING: 0.7.0~git20141116-1# (c++)"Json::Value::operator=(Json::Value
const&)@Base" 0.6.0~rc2
  (c++)"Json::Value::operator==(Json::Value const&) const@Base" 0.6.0~rc2
  (c++)"Json::Value::operator>(Json::Value const&) const@Base" 0.6.0~rc2
  (c++)"Json::Value::operator>=(Json::Value const&) const@Base" 0.6.0~rc2

Are you removed those method definition for any reason?. If those
changes could affect to an user I think I have to increase the SONAME in
Debian version, in order to avoid conflicts. What do you think?

[cdunn2001]

% git diff -w svn-release-0.6.0-rc2 32009b1 -- include/json/value.h
...
-         CZString &operator =( const CZString &other );
+    CZString &operator=(CZString other);
...
-      Value &operator=( const Value &other );
+  Value &operator=(Value other);

Yes, those 2 signatures have changed. Not good. (I am comparing tag svn-release-0.6.0-rc2 with commit 32009b17e4d35a812575cfcf6bae9ec49fc67446, which preceded our Clang reformatting.)

Let me see if I can add those back and delegate to the others. I'm not sure whether that would actually compile...

[cdunn2001]

Billy, 45cd949 broke binary compatibility. I don't want Debian to bump the .so version. So we have to consider some choices:

A. Revert this on the pre-C++11 branch.
B. Keep it, but add the old signatures too, and let those delegate to the new ones. Will that compile?
C. Keep it as is. Maybe it's not a real problem. (But I don't think we can convince Debian folks of that.)

I'm going with A for now. What do you think?

[BillyDonahue]

I would go with A as well. Revert on the branch Debian is pulling.
Or bump the patchlevel on the .so.

I didn't realize Debian would be pulling from a trunk branch and expecting
binary compatibility.
That seems like a pretty fragile setup!

On Mon, Nov 17, 2014 at 12:57 AM, Christopher Dunn <[email protected]

wrote:

Billy, 45cd949
45cd949
broke binary compatibility. I don't want Debian to bump the .so version. So
we have to consider some choices:

A. Revert this on the pre-C++11 branch.
B. Keep it, but add the old signatures too, and let those delegate to the
new ones. Will that compile?
C. Keep it as is. Maybe it's not a real problem. (But I don't think we can
convince Debian folks of that.)

I'm going with A for now. What do you think?

—
Reply to this email directly or view it on GitHub
#78 (comment)
.

[cdunn2001]

Yes, I think worrying about binary compatibility unwise. But in our case, it was easy. I'll tag that as 0.6.0.

I'm about to tag the tip as 0.7.0. Then I'll bump to 1.0.0 on master and call it officially C++11 only.