The biggest piece in the new 1.7.40 release is the new reference manual
documentation. I've spent nearly every working hour for the past 3
weeks since 1.7.35 was released adding material to the documentation,
most of it to the reference manual.
As a result of that slog, I added over two dozen new Wishlist items.
(There's nothing like trying to teach someone else how something works
to improve your own understanding of it!) The fixes for most of these
problems will break the ABI, so I finally feel confident that we have
enough material to justify at least two more major releases.
My current thinking is to push all of the straightforward ABI breakages
into v2.0, and leave the real features for v2.1. The point of this
split is to give us one more chance in the forseeable future to change
the ABI again if a change is not popular, or if more change seems to be
indicated. I decided on this because I know we won't get as much
testing in the beta phase as when it goes into production, so we should
plan to be able to change it again relatively soon. If we tried to pack
every Wishlist item into v2.0, there would have to be a v2.1 soon
Speaking of naming, I'm still considering how to better handle the
soname scheme. Currently, we just increment the library version number
every time the ABI changes. That isn't without precedent, but it would
be nice if the library sofile version had some relation to the MySQL++
version it comes from. I wonder if we can't actually go with the
literal version number; if there's a libmysqlpp.so.2.0.9 and a
libmysqlpp.so.4, which one does a program use if it just asks for
libmysqlpp.so? I seem to recall that that symlink is ultimately under
our control, so we could point it at the 2.0 library.
This soname issue is why I'm calling the next version 2.0, by the way,
and not 1.8 as I though I might earlier. The next major release _will_
break the ABI again, and we need to have the soname issue settled by
I haven't bothered to start splitting up the Wishlist into v2.0 and v2.1
parts, but I will soon if there are no objections to this plan.
Also planned for v2.0 is relicensing the documentation. I've received
tentative acceptance for this from Kevin Atkinson and the MySQL folk.
I'd hoped to have it finalized for the recent v1.7.40 release, but there
are some hold-ups still. It'll take a few more weeks to get this change
through the MySQL bureaucracy, Kevin doesn't want to sign off on it
until he sees the final plan, and on top of all that I haven't settled
on a license yet. For anyone who cares, I'm considering the Open
Publication License and the Creative Commons Attribution-ShareAlike
licenses now. The GNU FDL has been rejected, because Debian won't
accept packages using it.
|• Tentative v2.0 plans||Warren Young||27 May|