[Coin-discuss] yet another forgotten so-name change?

[Ted Ralphs]

On Sat, Feb 27, 2010 at 5:10 AM, Stefan Vigerske
<stefan at math.hu-berlin.de> wrote:
> Hi,
>
>>>>>>>>> But in addition coinor-osi fails to build since some things changed in
>>>>>>>>> the API right?
>>>>>>>> Yes. Osi 0.102 should work with CoinUtils 2.6.
>>>>>>> But why not 0.100.2 ...?
>>>
>>> Policy says that an API change requires at least a minor version bump.
>>> Bug fixes that don't change the API get point releases.
>>>
>>> I don't recall exactly what changed in each minor version update, but
>>> that's how it's designed to work.
>>
>> OK then, but how can I figure out which versions of packages are
>> required to get package X to work and how do I know that updating one
>> will break the whole chain?
>>
>> What I need is some kind of table saying e.g.
>>
>> coinor-osi 0.102.1 requires coinutils 2.6, libclp 1.11
>> ...
>
> One way to see this currently is to look at the externals of CoinAll.
> This is a quite comprehensive assembly of COIN-OR projects that are
> known to work together.
> The latest release was CoinAll 1.3.1 five months ago:
> https://projects.coin-or.org/CoinBinary/browser/CoinAll/releases/1.3.1/Externals
> The next one (CoinAll 1.4) is in preparation:
> https://projects.coin-or.org/CoinBinary/browser/CoinAll/stable/1.4/Externals

To add some more detail to the picture, there is a complete
description of the standard COIN versioning system here:

https://projects.coin-or.org/CoinTLC/wiki/VersionsAndReleases

and here:

https://projects.coin-or.org/BuildTools/wiki/pm-svn-releases#SuggestionsforHandlingStableVersionsandReleases

The most direct route to find dependencies for a particular project
and version is to look at the subversion externals in TRAC. If you go
to the URL in the TRAC source browser of the project you are trying to
use, the externals are listed at the bottom. For example, take a look
at

https://projects.coin-or.org/Osi/browser/releases/0.102.0

At the bottom of the page, you will see links to the appropriate
versions of all dependent projects.

The way that things are currently set up, when you download either
source or binaries for a project, you automatically get the correct
dependent versions. However, as you point out, it is not really easy
to upgrade individual packages to a new stable series after you have
installed a group of dependent packages (upgrading to a new patch
release should always be safe). It is also not easy to install
multiple projects within the same installation directory, since they
may have conflicting dependencies. This is something we are keenly
aware of and the TLC has made it a high priority to address it. We are
working on an improved build and installation, including library
versioning (.so names), easy installation and upgrade utilities for
all major platforms, utilities for easily determining dependencies,
etc. Stay tuned for details.

Cheers,

Ted
-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted