Versions in ports

[Daniel J. Luke]

> On Sep 16, 2015, at 5:17 AM, Artur Szostak <aszostak at partner.eso.org> wrote:
>>>>> And their newer versions are not backwards compatible with C 1.0, thus:
>>>> what is the nature of this incompatibility?
>>> 
>>> Two examples that I can think of that affect the kind of software I work with are:
>>> 1) The internal algorithm of some API functions have changed, even though the
>>> API interface has not. This might lead to different results for certain invocations
>>> of these functions.
>> 
>> this would be a bug in that software
> 
> I disagree. There is a large body of software that changes its internal algorithms without changing the API. First obvious examples would be math libraries, BLAS and other linear algebra libraries. Just because the internal algorithm changed, does not make it a bug as long as library version numbers are updated appropriately.

If the API changes and the library version numbers are updated, ref-upgrade will catch this.

I’m saying it’s a bug if the library pretends to offer the same API but acts differently.

it’s OK if we disagree ;-) Lots of projects don’t want to spend time thinking about compatibility between versions (which is probably one of the reasons why no one has tackled adding version information to dependencies in macports yet).

>>> 2) The command line interface for certain programs has changed, which are used
>>> under the hood by higher level tools.
>> 
>> and this also if the command line interface was meant to be an interface to other programs
> 
> Again I disagree. Why would it be a bug to add CLI options to a program and bump its version number? More or less the same rules could apply as is used for library versioning.

the way we would normally handle this in macports would be to a port for the each version of the program, so they could co-exist and ‘port upgrade foo’ wouldn’t break anything.

of course, it’s up to the maintainer(s) to notice when something like that happens and they might miss it.

— 
Daniel J. Luke                                                                   
+========================================================+ 
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+ 
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+