Daniel, if it makes it easier for maintenance, then by the X=2-3 years policy we can even drop anything before Boost 1.40 (only if supporting 1.36 is a lot of effort - of course it's always fine to keep it if it's not too much hassle)
On Tue, Aug 7, 2012 at 11:13 AM, Daniel Russel drussel@gmail.com wrote:
> Yeah, sorry, I was a bit sloppy. 1.49 is the last supported version, not > the first dropped version. > > On Aug 7, 2012, at 10:52 AM, Yannick Spill yannick@salilab.org wrote: > > personnally I use 1.49 on both my mac and my @pasteur.fr machine. > > Le 07/08/12 19:21, Daniel Russel a écrit : > > 1.33 is 6 years old (what we support) > 1.36 is 4 years old (we often check for versions older than this to work > around things) > 1.40 is 3 years old (current centos) > 1.46 is 1.5 years old (boost filesystem v3 introduced) > 1.51 is in beta now > > On Tue, Aug 7, 2012 at 10:05 AM, Barak Raveh barak@salilab.org wrote: > >> I am really ignorant about boost versions and file systems, just curious >> - how old are the various versions? What happens if we try to apply the X=2 >> years or so policy? >> >> >> >> On Aug 7, 2012, at 9:58 AM, Daniel Russel drussel@gmail.com wrote: >> >> > Boost has dropped support for filesystem v2 as of 1.49, so >> directories.cpp needs to be patched. It is already a mess with trying to >> support the various permutations of things (VC or not, boost < 1.35, boost >> < 1.36, and now boost filesystem v2 vs v3, no boost file system) so it >> would be really nice to simplify it. Some options are: >> > 1) only support boost.filesystem v3 (with windows) or no >> boost.filesystem: the motivation being that this is the way forward and >> there is no reason on windows not to be using the latest boost since there >> is no pre-installed version. The down side is that CentOS 6 doesn't have >> v3. But there is all the backwards compatibility there. >> > 2) drop support for boost < 1.36 and not having boost.filesystem, so >> only support fileysystem v2 and v3 (and perhaps only v3 with windows). I >> don't see any reason why someone would have some boost libraries and not >> others, and if you don't have any, an awful lot of IMP goes away. And when >> queried before, no one actually had a useful machine running such an old >> boost version (I'll post on the user list to get a, perhaps, wider sample). >> > 3) drop support for boost filesystem. We currently have workarounds >> that work on windows, mac and unix/linux systems, so this isn't much work. >> But it makes it hard to add extra functionality as we move forward. >> > >> > Thoughts? I'm for 2. >> > _______________________________________________ >> > 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 >> > > > > _______________________________________________ > IMP-dev mailing listIMP-dev@salilab.orghttps://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > 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 > >