Policy for versions of IMP dependencies
As Ben just had to patch something to handle a very old version of boost, I think it might be worth thinking a bit about how our requirements for versions of third party libraries change over time. When IMP started, we decided we needed to support versions of dependencies (boost, swig, scons, python, gcc etc) that are part of the mainstream platforms, eg things like - latest RHEL/CentOS - latest ubuntu - latest XCode/macports - the version of visual studio on Ben's test machine :-) (also homebrew and fedora, but they are, in general, strictly newer than things on the list)
So far we have more or less stuck with the versions of the dependencies, rather than the policy (eg, I don't think any of those use boost 1.33 but we still require that we support it). It seems to me it might make sense to keep these as the live requirements, that is, drop old versions as they become older than the versions in the list above.
I think the main immediate effect would be to update to boost 1.40, and gcc 4.4, which would remove a bunch of work around and open things up for a number of boost libraries (foreach for example) and CXX11 features (perhaps even auto and range based for loops :-) although we would have to check with visual studio and the apple compilers).
On 07/30/2012 04:13 PM, Daniel Russel wrote: > As Ben just had to patch something to handle a very old version of > boost
Well, I didn't have to, but it seemed easy enough to fix rather than having to drop support for RHEL 5.
> So far we have more or less stuck with the versions of the dependencies, > rather than the policy (eg, I don't think any of those use boost 1.33 > but we still require that we support it). It seems to me it might make > sense to keep these as the live requirements, that is, drop old versions > as they become older than the versions in the list above.
Sure, I don't think it unreasonable to require RHEL 6 rather than 5 now.
> I think the main immediate effect would be to update to boost 1.40, and > gcc 4.4
Are you suggesting that users have to have the latest release of OS X on Mac? Right now things will build all the way back to 10.4 - although I'm not suggesting we need to support that forever - but I think it unreasonable to expect everyone to use Mountain Lion, for example. Snow Leopard is still at gcc 4.2, and a lot of people (even in the Sali lab) still use that.
Ben
I also think we should maintain some backward compatibility, perhaps replace the word "support latest e.g. ubuntu" with "support versions of ubuntu from last XX years". We may require some new dependenciews here and there, but we don't want users to have to update their entire system every six months (or even a year) in order to use IMP. Barak
On Mon, Jul 30, 2012 at 4:21 PM, Ben Webb ben@salilab.org wrote:
> On 07/30/2012 04:13 PM, Daniel Russel wrote: > >> As Ben just had to patch something to handle a very old version of >> boost >> > > Well, I didn't have to, but it seemed easy enough to fix rather than > having to drop support for RHEL 5. > > > So far we have more or less stuck with the versions of the dependencies, >> rather than the policy (eg, I don't think any of those use boost 1.33 >> but we still require that we support it). It seems to me it might make >> sense to keep these as the live requirements, that is, drop old versions >> as they become older than the versions in the list above. >> > > Sure, I don't think it unreasonable to require RHEL 6 rather than 5 now. > > > I think the main immediate effect would be to update to boost 1.40, and >> gcc 4.4 >> > > Are you suggesting that users have to have the latest release of OS X on > Mac? Right now things will build all the way back to 10.4 - although I'm > not suggesting we need to support that forever - but I think it > unreasonable to expect everyone to use Mountain Lion, for example. Snow > Leopard is still at gcc 4.2, and a lot of people (even in the Sali lab) > still use that.
> > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > ______________________________**_________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >
On 07/30/2012 04:35 PM, Barak Raveh wrote: > I also think we should maintain some backward compatibility, perhaps > replace the word "support latest e.g. ubuntu" with "support versions of > ubuntu from last XX years". We may require some new dependenciews here > and there, but we don't want users to have to update their entire system > every six months (or even a year) in order to use IMP.
Well, if "XX" is more than 1.05 then we have the current situation. ;) (CentOS 6 was released Jul 10, 2011.) Are you suggesting XX should be 1?
Ben
I had 2-3 years in mind :) quite an arbitrary figure though.
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...
On Mon, Jul 30, 2012 at 4:45 PM, Ben Webb ben@salilab.org wrote:
> On 07/30/2012 04:35 PM, Barak Raveh wrote: > >> I also think we should maintain some backward compatibility, perhaps >> replace the word "support latest e.g. ubuntu" with "support versions of >> ubuntu from last XX years". We may require some new dependenciews here >> and there, but we don't want users to have to update their entire system >> every six months (or even a year) in order to use IMP. >> > > Well, if "XX" is more than 1.05 then we have the current situation. ;) > (CentOS 6 was released Jul 10, 2011.) Are you suggesting XX should be 1? > > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle >
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
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 ben@salilab.org 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 > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle >
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 barak.raveh@gmail.com 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 ben@salilab.org 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 > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > > > > -- > Barak > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
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 drussel@gmail.com 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 barak.raveh@gmail.com 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 ben@salilab.org 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 >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> > > > > -- > Barak > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > >
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 barak.raveh@gmail.com 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 drussel@gmail.com 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 barak.raveh@gmail.com 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 ben@salilab.org 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 >>> -- >>> ben@salilab.org http://salilab.org/~ben/ >>> "It is a capital mistake to theorize before one has data." >>> - Sir Arthur Conan Doyle >> >> >> >> >> -- >> Barak >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > > > > -- > Barak > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
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 barak.raveh@gmail.com 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 drussel@gmail.com 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 barak.raveh@gmail.com 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 ben@salilab.org 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 >>>> -- >>>> ben@salilab.org http://salilab.org/~ben/ >>>> "It is a capital mistake to theorize before one has data." >>>> - Sir Arthur Conan Doyle >>> >>> >>> >>> -- >>> Barak >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >> >> >> -- >> Barak >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
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 <drussel@gmail.com > mailto:drussel@gmail.com> 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 <barak.raveh@gmail.com > mailto:barak.raveh@gmail.com> 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 <ben@salilab.org >> mailto:ben@salilab.org> 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 >> -- >> ben@salilab.org mailto:ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> >> >> >> >> -- >> Barak >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org mailto:IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > > > -- > Barak > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On 7/31/12 11:50 AM, Javier Velazquez-Muriel wrote: > 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.
We do support Windows, so no problem there. IMP builds with a recent version of Visual Studio Express (our build host uses 2010) which is free. In principle it would build with gcc on Windows too, but I don't think anybody ever tried that.
Ben
Just to clarify, what is difficult is getting IMP to build on Windows, not getting IMP to build for Windows, which Ben does using Wine. The complications with getting it to build on Windows come from getting the various tools needed (scons, swig, python, shells, visual studio etc) working with one another and agreeing on the ways to pass paths and such around.
On Jul 31, 2012, at 12:48 PM, Ben Webb ben@salilab.org wrote:
> On 7/31/12 11:50 AM, Javier Velazquez-Muriel wrote: >> 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. > > We do support Windows, so no problem there. IMP builds with a recent version of Visual Studio Express (our build host uses 2010) which is free. In principle it would build with gcc on Windows too, but I don't think anybody ever tried that. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
My comment was sort-of-ironic. I couldn't help it. When I hear all the discussion about our mac micro-world I can't help raising an eyebrow. Nobody has tried Windows, I am almost certain, and I don't care too much. But I don't think that anybody has run anything on mac that is worth commenting about. It is good to have some perspective, isn't it?
On 7/31/12 1:03 PM, Javier Velazquez wrote: > My comment was sort-of-ironic. I couldn't help it. When I hear all the > discussion about our mac micro-world I can't help raising an eyebrow.
Well, the discussion doesn't really pertain to Windows, since Windows doesn't ship with any of the tools needed to build IMP anyway (e.g. Python, boost, C++ compiler) so the user would have to download them separately from the OS (and there's no reason not for them to install a relatively new version of each, even if they have an old OS). MS is pretty good with backwards compatibility - all the latest tools will run on Windows 2000, which is over 10 years old now.
> Nobody has tried Windows, I am almost certain, and I don't care too > much.
We build and test on Windows as part of the nightly builds, and I know at least some people have used the binary installs.
Ben
Now seriously.
It is good to offer some backwards compatibility. And perhaps some sort of "forward-compatibility warning", no? For example, em2d will work with OpenCV 2.1, 2.2, 2.3. I have not tried the 2.4, which is just released. A user with the new OpenCV version may want to know that I can guarantee that the things work up to 2.3.
On Tue 31 Jul 2012 01:03:34 PM PDT, Javier Velazquez wrote: > > My comment was sort-of-ironic. I couldn't help it. When I hear all the > discussion about our mac micro-world I can't help raising an eyebrow. > Nobody has tried Windows, I am almost certain, and I don't care too > much. But I don't think that anybody has run anything on mac that is > worth commenting about. It is good to have some perspective, isn't it?
On 7/31/12 1:21 PM, Javier Velazquez wrote: > It is good to offer some backwards compatibility. And perhaps some sort > of "forward-compatibility warning", no? For example, em2d will work with > OpenCV 2.1, 2.2, 2.3. I have not tried the 2.4, which is just released. > A user with the new OpenCV version may want to know that I can guarantee > that the things work up to 2.3.
This is what modules/em2d/doc/SConscript is for. I agree that it would be nice if it contained some useful information. ;)
Ben
> > 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... I think there is some of both. Switching to support things like auto would be huge simplification of various things. But other places it is just removing a second, rarely used, code path that we have to maintain. Or removing part of IMP that only works on some of the supported systems.
> Sure, I don't think it unreasonable to require RHEL 6 rather than 5 now. Agreed. It seems like most setups get upgraded within 6 months or a year of the next release. So phasing out along that sort of time frame makes sense.
> >> I think the main immediate effect would be to update to boost 1.40, and >> gcc 4.4 > > Are you suggesting that users have to have the latest release of OS X on Mac? Right now things will build all the way back to 10.4 - although I'm not suggesting we need to support that forever - but I think it unreasonable to expect everyone to use Mountain Lion, for example. Snow Leopard is still at gcc 4.2, and a lot of people (even in the Sali lab) still use that. Just to add an *, it is a heavily modified gcc 4.2, I think (Mountain Lion's gcc is also 4.2).
I'm not saying we drop old versions immediately (nor that we go and break backwards compatibility out of spite :-).
participants (7)
-
Barak Raveh -
Ben Webb -
Daniel Russel -
Dina Schneidman -
Javier Velazquez -
Javier Velazquez-Muriel
-
Yannick Spill