List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:June 20 2010 10:35pm
Subject:Re: v3.1.0 imminent
View as plain text  
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.
Thread
v3.1.0 imminentWarren Young13 May
  • Re: v3.1.0 imminentRick Gutleber14 May
    • Re: v3.1.0 imminentWarren Young14 May
      • Re: v3.1.0 imminentRick Gutleber14 May
  • Re: v3.1.0 imminentRemi Collet19 May
    • Re: v3.1.0 imminentWarren Young19 May
      • Re: v3.1.0 imminentWarren Young19 May
        • Re: v3.1.0 imminentJonathan Wakely20 May
      • Re: v3.1.0 imminentRemi Collet20 Jun
        • Re: v3.1.0 imminentJonathan Wakely20 Jun
          • Re: v3.1.0 imminentWarren Young21 Jun
            • Re: v3.1.0 imminentRemi Collet21 Jun