Re: [IMP-dev] Policy for versions of IMP dependencies
To: List for IMP development <>
Subject: Re: [IMP-dev] Policy for versions of IMP dependencies
From: Yannick Spill <>
Date: Tue, 31 Jul 2012 22:36:21 +0200
Reply-to: List for IMP development <>
Same here! I'm using snow leopard and not planning to change that.
Le 31/07/12 20:44, Dina Schneidman a écrit :
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