Keeping dependencies up to date

Part of making software available and usable to everyone includes keeping the dependencies up to date… I already discussed a few things about this in Making open source software available post and promised a later updates… well it won’t be this time :)

Anyway, we had a veeeeery bad time upgrading the outdating Ogre 1.4 to the fresher Ogre 1.7.

I truly have difficulties to understand the way the Ogre team is managing there releases. First, I think each version of Ogre I tested in the past lead me to modify our code because of API changes. Second, Ogre almost can’t be used standalone and relies on several almost mandatory dependencies such as Object Oriented Input System (or OIS) or Crazy Eddie’s GUI System (or CEGUI). In almost mandatory, I mean even if those libraries are not part of Ogre, some of their binaries are usually distributed with Ogre and most example use them. The CEGUI module that provides CEGUI functionalities within Ogre used to be maintained by the Ogre team. For the 1.7 Ogre release, this module was removed from Ogre, and directly integrated in the CEGUI sources, should now be maintained by the CEGUI team… Of course, the header / namespaces / whatever changed… :) and the most surprising part was that the officially released win32 CEGUI package – at the time we did OpenViBE 0.6.0 – lacked a few symbols and could not be linked with Ogre 1.7…

Damn, its hard to make a stable software based on those dependencies. A few years in the past, we wondered which of Ogre3D or VTK would be the best for OpenViBE to include. We chose Ogre3D because several engineers in our team had success stories with it. Well today, I believe that VTK would be less time consuming in maintenance…

Should I say a few words about Boost and their precompiled windows binaries that disappear from sourceforge as a new version comes out ?

2 Comments to “Keeping dependencies up to date”

  1. cloderic 3 May 2010 at 11:04 pm #

    Hum…

    It’s not that simple, backward compatibility at all cost is what kills lots of API (think win32). Tough, i perfectly understand your reluctance to spend time upgrading to newer versions when API has changed.

    The real question is, i think, would you rather handle slight changes in the API each time or a revolution once the software is obsolete and rewritten from scratch ?

    • Yann Renard 5 May 2010 at 11:56 am #

      Well, having to replace

      l_pEntity->getParentSceneNode()->getWorldTransforms(&l_oMatrix4);

      by

      l_oMatrix4=l_pEntity->getParentSceneNode()->_getFullTransform();

      does not look like a change in anyway, except the API breakage.
      That was the same for what I pointed out in CEGUI (they renamed class COgreCEGUIRenderer to class CEGUIOgreRenderer, etc).

      More generally speaking, some code may be deprecated. Such code may disapear from the documentation or be documented as such. However, this does not freeze the functionnalities and if the new functionnalities need an API replacement, then this becomes a new major version.

      I think the API should be maintained at least until the new major version. This is what is done with OpenViBE. Some parts of the API should already not be used but they are still present. They won’t evolve in the future and needing the new features will force the developpers to move on to the new API. However, their code will still work until then !

      This is a matter of trust between each software component I guess.