[Osi] OsiGlpk evolution: is backward compatibility important?

[Lou Hafer]

Folks,

	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
maintain.

	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
     back.

     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).

							Lou