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: Javier Velazquez-Muriel <>
Date: Tue, 31 Jul 2012 11:50:24 -0700
Cc: Daniel Russel <>
Reply-to: List for IMP development <>
Sorry to tell you, loyal followers of Steve Jobs, but a good chunk of
the world uses Windows. It is probably installed in more machines, and
on par or more powerful. Who is going to buy a high end mac desktop
having PCs for half the price? Who is going to run the computer
intensive tasks of IMP on a mac laptop anyway? Do you want more users?
Think in terms of percentages. Support Windows. My feel is that most of
the users will use it on Linux though.
On Tue Jul 31 11:39:50 2012, 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 <
<">mailto:>> 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 <
<">mailto:>> 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 <
<">mailto:>> 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
--
<">mailto:> http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle
--
Barak
_______________________________________________
IMP-dev mailing list
<">mailto:>
https://salilab.org/mailman/listinfo/imp-dev