GNOME Bugzilla – Bug 754673
API/ABI-breaking libxml++ 3.0 release
Last modified: 2016-02-02 12:22:20 UTC
This bug is intended for the development of a new API/ABI-breaking libxml++ 3.0 release. See also https://mail.gnome.org/archives/libxmlplusplus-list/2015-September/msg00001.html Bugs to fix: Bug 338907 "const_NodeList" instead of "const NodeList" Bug 632522 Document::get_root_node() should have const and non-const versions. Bug 632524 Element::get_attribute() should have const and non-const versions. Bug 753123 Don't use deprecated std::auto_ptr TODO comments that suggest ABI-breaking fixes shall be considered, and in most cases fixed. Questions: What's the best way to proceed? Create a new branch (gnome-3-0tmp?) and merge it with the master branch when it's time to release libxml++ 3.0.0? Release libxml++ 2.40.0, create a gnome-2-40 branch, and then make ABI-breaking changes on the master branch?
(In reply to Kjell Ahlstedt from comment #0) > Release libxml++ 2.40.0, create a gnome-2-40 branch, and then make > ABI-breaking > changes on the master branch? This is simplest, though we don't need to wait for the libxml++ 2.40.0 release. We should probably use a more libxml++--specific branch name from now on. Thanks.
What to do then? Create a gnome-2-40 (or libxmlpp-2-40) branch now, and use it for patches that will lead to future 2.40.x releases?
Yes, that sounds good.
Branch name? gnome-2-40 or libxmlpp-2-40 or libxml++-2-40 or something else?
I guess we don't need to be afraid of the plus character these days. libxml++-2-40 should be fine, and is consistent with other *mm projects.
I've started the route to libxml++ 3.0 by creating a libxml++-2-40 branch and replacing 2.6 by 3.0 in configure.ac and other files. https://git.gnome.org/browse/libxml++/commit/?id=2da7d1ea4502c5054fe966291c830482048a13c2 More modifications (in addition to those mentioned in comment 0) that shall go into libxml++ 3.0: - Remove deprecated code (class Schema and class SchemaValidator). But retain MM_ARG_DISABLE_DEPRECATED_API([LIBXMLXX]). We will need it again some time. - Remove LIBXMLCPP_EXCEPTIONS_ENABLED, which is unconditionally defined now.
I've fixed the 4 bugs listed in comment 0. I've also fixed TODO comments that require ABI or API break in the parser and validator classes. Deprecated code is gone. About half of the job is done (rough estimation). The node classes and other classes remain to be fixed.
libxml++/document.h contains the comment //TODO: Make Document inherit from Node, when we can break ABI one day? libxml++/dtd.h contains //TODO: Derive from Node? The enum xmlElementType contains the enum constants XML_DOCUMENT_NODE and XML_DTD_NODE. Those constants are handled in some Node methods, e.g. create_wrapper(). Libxml2 treats documents and DTDs partly as nodes, but I'm not sure it should be done in libxml++, for two reasons: - If you look at node.h, document.h and dtd.h, there's only a faint resemblance. Very few methods are common to node.h and either document.h or dtd.h. - More important: From the user's point of view, it's not a natural class hierarchy. A document is not a node. A document contains a tree of nodes. A DTD is not a node. It's a description of what a valid document looks like. It has more in common with the schema definitions RelaxNGschema and XsdSchema, which are alternative ways of describing a valid document. I vote for letting Document and Dtd remain separate from Node. Comments? Another question: The Node class contains many methods. Some of them are applicable only to certain types of nodes. E.g. add_child() and friends are applicable only to Element nodes. If *this is not an Element node, they throw an exception. Is this really good? Wouldn't it be better to remove those methods from Node, and add them to Element? On the other hand, I can imagine situations where it's nice to be able to call them with node->add_child(), where node is a Node*, without having to use dynamic_cast.
The master branch now contains a first attempt at what can become a new libxml++ 3.x release. Gtkmm 3 was preceded by 2.90.0 and other 2.9x.x releases. Is that the way to proceed with libxml++ too? Now release an unstable libxml++ 2.90.0? Then possibly more 2.9x.x releases before 3.0.0? Shouldn't it be 2.91.0 or some other odd number instead of 90, to show that it's unstable?
2.91.1 would be best, I think, to avoid anybody thinking that it's a stable release because of an even number.
I have released libxml++ 2.91.1. > Remove LIBXMLCPP_EXCEPTIONS_ENABLED, which is unconditionally defined now. I forgot it. But it's the least important change to get into 3.0.0. I can do it later, or let LIBXMLCPP_EXCEPTIONS_ENABLED remain in 3.x. Some TODO comments remain in the code: - The suggestion to let Document and Dtd be subclasses of Node. I prefer not to implement them unless someone can me a good enough reason. See comment 8. - Comments that suggest non-ABI-breaking changes. I've given very little thought to those suggestions. They can be implemented any time, even after the 3.0.0 release.
It's time for libxml++ 3.0.0, I think. I don't plan more changes now. Perhaps first a 2.91.3 release? I've made some API/ABI breaking changes since 2.91.2. (2.91.2 was the result of bug 757042.)
Another 2.91 release seems wise. And we should let it be known more widely that libxml++ 3.0.0 will be released soon, so people have a chance to suggest ABI-breaking changes before then. People always seem to mention that stuff right after a .0 release.
I have mentioned in the release message for 2.91.3 that 3.0.0 will happen soon, and I've posted a message on libxmlplusplus-list. Are there other good ways of letting people know?
Not everyone is happy that I've released several ABI-incompatible versions of libxml++ without changing the version number that's part of the name of the .so file (bug 760574). Wasn't the transition from gtkmm 2 to gtkmm 3 done like that? Weren't all gtkmm 2.9x.y versions released with the same .so name, although there were ABI-breaks along the way from 2.90.0 to 3.0.0? Who decides if we're allowed to do that with unstable releases? The name of the .so file does not tell if the file is generated from a stable or an unstable release. That could perhaps be a problem.
(In reply to Kjell Ahlstedt from comment #15) > Not everyone is happy that I've released several ABI-incompatible versions of > libxml++ without changing the version number that's part of the name of the > .so > file (bug 760574). > > Wasn't the transition from gtkmm 2 to gtkmm 3 done like that? I don't remember. If we didn't do it, people probably complained. There's no harm in doing it now, until we hit .0. And if we didn't do it that would be because we'd got into the habit of not doing it during development cycles after the ABI has become stable. In that case (not this case) the logic is that we do want to break ABI of new API until that API is stable. But we don't want it to then look like we broke ABI of stable API.
"git blame" shows the date of last modification of some lines configure.ac files. gtkmm/configure.ac 2010-05-12 MM_INIT_MODULE([gdkmm-3.0]) 2010-05-12 MM_INIT_MODULE([gtkmm-3.0]) 2009-10-04 AC_SUBST([LIBGTKMM_SO_VERSION], [2:0:1]) glibmm/configure.ac 2009-08-16 MM_INIT_MODULE([glibmm-2.4]) 2009-08-16 MM_INIT_MODULE([giomm-2.4]) 2010-01-02 AC_SUBST([LIBGLIBMM_SO_VERSION], [4:0:3]) The libtool version (so version) rules, described at http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html https://developer.gnome.org/programming-guidelines/stable/versioning.html.en have not been followed by gtkmm and glibmm for many years. The latest SO_VERSION bumps were made when gtkmm 2.18.2 and glibmm 2.23.0 were released.
Do you think it's time to release libxml++ 3.0.0? No one has suggested any changes lately.
That sounds reasonable. Thanks for waiting just in case.
libxml++ 3.0.0 has been released.