Re: [IMP-dev] Policy for versions of IMP dependencies

[Dina Schneidman <>]

completely agree, I am one of those users who can stay happily with
the same OS for 3 years :)
"if it works, don't touch!"

On Tue, Jul 31, 2012 at 11:39 AM, Barak Raveh <> wrote:
> I believe backward compatibility = more potential users. Snow leopard was
> released 3 years ago and Apple ended it support only this July
> (unofficially). It still must have millions of people that have it on their
> lap-tops (some in our lab?). Why losing them as potential IMP users if it is
> not absolutely necessary? I believe we should be certain we provide very
> important functionalities before we drop backward compatibility (this also
> goes for dependencies), since usually, there's no good reason for it.
>
> On Tue, Jul 31, 2012 at 11:17 AM, Daniel Russel <> wrote:
>>
>> It is really not clear to me how much backwards support is worth it.
>>
>>
>> For mac os, Apple doesn't do patches for versions older than the current
>> -1, I believe. So no one should be running 10.6 at this point as they can't
>> get security updates. So supporting that doesn't seem worthwhile.
>>
>> For linux, everywhere I have been it is either upgrade within 6 months or
>> so of CentOS/RHEL/Ubuntu being upgraded or upgrade to every other version of
>> Fedora. So again, its not clear that we benefit anyone by supporting older
>> versions here either.
>>
>> For windows, I don't think anyone else will manage to build IMP :-) (I
>> failed twice), so supporting old compilers there doesn't buy us much either.
>>
>> So while it seems nice in theory, I don't see that there is much benefit
>> in practice to go far back. Has someone been at an institution where older
>> than the above was used?
>>
>> On Jul 30, 2012, at 5:16 PM, Barak Raveh <> wrote:
>>
>> Good point (and Daniel said something similar in different words I think).
>>
>> So perhaps as a policy, we can say: "we give XX (2-3) years backward
>> compatibility, but for rare and true necessities (e.g., python
>> multiprocessing), you must upgrade your dependencies in order to use IMP
>> since it's too important and helpful ; And if possible and not too
>> complicated, we will strive to provide partial functionality even without
>> such upgrade (e.g., you will have IMP but without python multiprocessing)."
>>
>>
>> On Mon, Jul 30, 2012 at 4:56 PM, Ben Webb <> wrote:
>>>
>>> On 07/30/2012 04:52 PM, Barak Raveh wrote:
>>>>
>>>> I had 2-3 years in mind :) quite an arbitrary figure though.
>>>
>>>
>>> Right, this is how I chose the most recent versions of Boost to support
>>> originally. But it makes sense to agree on an "XX" as you suggest. I think 2
>>> years is reasonable.
>>>
>>>
>>>> It's just that flawed backward compatibility is usually not due to
>>>> amazing technological breakthroughs we cannot live with out, but
>>>> probably due to some package changing the name of function X to function
>>>> Y, or a few #include statements that need to be altered...
>>>
>>>
>>> True, I think we can live without some fancy CXX11 features. More
>>> annoying is the lack of some Boost classes and Python modules (only very
>>> very recent versions of Python ship with the multiprocessing module, for
>>> example).
>>>
>>>
>>>         Ben
>>> --
>>>                       http://salilab.org/~ben/
>>> "It is a capital mistake to theorize before one has data."
>>>         - Sir Arthur Conan Doyle
>>
>>
>>
>>
>> --
>> Barak
>> _______________________________________________
>> IMP-dev mailing list
>> 
>> https://salilab.org/mailman/listinfo/imp-dev
>>
>>
>
>
>
> --
> Barak
>
> _______________________________________________
> IMP-dev mailing list
> 
> https://salilab.org/mailman/listinfo/imp-dev
>