[Osi] OsiGlpk evolution: is backward compatibility important?
ted at lehigh.edu
Wed Oct 29 18:54:10 EDT 2008
At the root of the entire discussion seems to be the implicit question
of whether we should treat third party dependencies differently from
dependencies on other COIN projects. I think the answer to that question
is potentially different for third party projects that are open source
versus commercial, but in the case of a third party project that is open
source, I don't really see a reason it should be handled any differently
than any other external. Do you? If that is the case, then I think the
way is pretty clear. When a new stable version of CoinUtils comes out,
for instance, and a new stable version of Osi is then later created that
depends on the new version of CoinUtils, there is no attempt to maintain
backwards compatibility with the older version of CoinUtils. It is
assumed that everyone will want to upgrade to the latest CoinUtils. Why
not? And why should glpk be any different? If the user is upgrading Osi
anyway, it should be completely transparent to also upgrade glpk. And
there is an automatic script to make it happen. Of course, this argument
breaks down in the case of commercial codes, but that is not the
Actually, the way things are currently set up, it would be difficult to
allow users NOT to upgrade, since (I think) you will need to specify a
specific version of ThirdParty/Glpk in the externals of OsiGlpk and
configuration will fail unless the version of Glpk it expects to find is
actually present. I'm not too sure about how this works if one checks
out Osi as a separate project, but in any case, checking it out with Cbc
or SYMPHONY and attempting to build will not work without the latest
version of Glpk.
In any case, best practices would dictate that we should be fixing
reported bugs in old versions of any COIN code that people are still
using, provided they have a good reason for not upgrading (within limits
of course). There are many reasons why someone may not want to upgrade,
not the least of which is because the newer version may not build with
older compilers. There was recently a post on coin-discuss about that
With all that said, it seems to me that option 4 is the one that is
really consistent with current recommended best practices and the one I
think should be adopted in principle, but option 5 is the one consistent
with actual current practices.
Lou Hafer wrote:
> The glpk lp solver is undergoing an API change which presents a
> challenge for backward compatibility in OsiGlpk. Stefan Vigerske and I have
> exchanged a few emails about this, and we thought it would be useful to
> engage a larger audience. There are two questions:
> * Specifically for OsiGlpk, is there user interest in maintaining backward
> compatibility for glpk versions 4.31 and earlier?
> * More generally, for any OsiXXX, how do maintainers and users feel about
> maintaining backward compatibility? If XXX is a commercial solver with
> a fee for upgrades, the question becomes more pointed. This question
> aims to get some feedback for the evolution of the Osi project.
> What follows is written to OsiGlpk, but Stefan and I would welcome
> suggestions for alternate strategies. If you just want to speak to the second
> question, you can stop reading now and post a comment.
> The glpk API is undergoing a global change in naming convention as well
> as ongoing changes in semantics of some routines and new capabilities. Clearly
> OsiGlpk needs to support the new API. Stefan's opinion, which I second, is that
> maintaining backward compatibility will be a trick. We could easily end up with
> code littered with #if GLPK_VERSION statements, unreadable and difficult to
> Here is a range of alternatives that we're considering. To avoid
> undue suspense, we're leaning towards 5), moving to the new API and
> declaring the old API obsolete and unmaintained.
> 1) Freeze OsiGlpk at glpk 4.31 for a while and allow glpk to settle on the
> new API. Re-evaluate once the dust settles.
> Really just postpones the problem, but worth a moment's thought. The
> old API will probably exist for another version or two.
> 2) Set up inline wrappers for the glpk API routines used in OsiGlpk. That
> would concentrate the majority of `#if GLPK_VERSION' statements in one
> place. The majority of the code would remain readable.
> A high level of short-term pain, but offers flexibility going forward.
> Wrappers could do actual work in those cases where there are real
> differences between the old and new APIs.
> There's a certain feel of recursion here. OsiGlpk is already a wrapper.
> In many cases the only change is the glpk API function name, but still
> it's another layer.
> 3) Maintain OsiGlpk_oldAPI.cpp and OsiGlpk_newAPI.cpp.
> OsiGlpkSolverInterface.cpp becomes a wrapper that includes the correct
> body based on glpk version.
> Doable for two versions, perhaps, with some discipline when doing
> upgrades and bug fixes.
> 4) Maintain Osi/stable 0.99 with glpk 4.31. Osi/trunk and future stable
> releases move forward with glpk 4.32 and the new API.
> A pain to maintain, but might work for a while. Trouble comes when some
> external referenced by the Osi package fixes an important bug, and the
> fix is not compatible with Osi 0.99 code. (But we're considering folks
> who are willing to forgo glpk bug fixes in order to stick with an older
> version of glpk.)
> 5) Convert Osi/trunk to the new API and follow through with Osi/stable
> when the time comes. Declare glpk <= 4.31 historical and never look
> By far the easiest choice for us as maintainers. My impression, from
> lurking on the glpk mailing list, is that Andrew has no sympathy for
> people reporting problems with earlier versions. He tells them to
> upgrade. This also matches the existing COIN practice. We don't do new
> stable versions quite so often, but we tend to abandon the old ones.
> Both Stefan and I like this approach (no surprise :-).
> In the past, I've advocated backward compatibility. But given that glpk is
> open source, Andrew's bias towards upgrades, and COIN practice, alternative
> 5) may be the right choice for OsiGlpk. If backward compatibility is
> desireable, I (Lou) would lean towards 2) with a bit of 3) if needed. Stefan
> leans towards 3) or 4). I suspect we'd converge on 3).
> Osi mailing list
> Osi at list.coin-or.org
Dr. Ted Ralphs
Associate Professor, Lehigh University (permanent)
Senior Fellow, Institute for Advanced Studies, Università di Bologna
ted 'at' lehigh 'dot' edu
More information about the Osi