On Jun 20, 2010, at 1:50 PM, Jonathan Wakely wrote:
> If the intention is that v3.0.x and v3.1.x are compatible
That's what the version number promises, yes.
> the ABI breakage should be fixed.
Certainly.
I suspect I'm going to have to remove some functionality, defer it for 4.0, but I don't
have time to look into it any sooner than later tonight.
One thing I don't currently intend to do is jump straight to 4.0, because then I'd have to
do all the ABI-breaking things I've been putting off for 4.0. It feels a bit too early to
have another tectonic library compatibility shift. I want to increase the time between
these, and right now it's been about as long between 3.0.0 and HEAD as it was between
2.0.0 and 3.0.0.
I'm willing to be swayed on that. I solicit opinions from anyone reading this: how long
do you wish for MySQL++ to keep a stable ABI?
I don't have a strong feeling for when I'd be comfortable switching to 4.0. Arbitrarily,
let's say "after RHEL 6 comes out". I'll feel less constrained from breaking things for
a year or two afterward, since Ubuntu 10.04 LTS is also out now.
Remi, does the fact that MySQL++ is in Fedora mean it will be in one of the default RHEL 6
repos? If not, I probably shouldn't be rubberbanding MySQL++'s schedule to RHEL's.
> you could bump the filename to .so.4 for 3.1.0
I used to do that back in the 1.x days, but I got quite a few complaints, even though
libmysqlclient.so is numbered the same way. Besides, it's a maintenance hassle to use a
different version number in mysql++.bkl and configure.ac.
> Or if you want the library version to correspond to the numbers in the
> shared library filename the soname could change so that apps link
> against .so.3.1 rather than .so.3
I'm not sure Bakefile knows how to do that. libtool does, but Bakefile doesn't use
libtool.
