On Mon, Sep 12, 2016 at 9:51 AM, Radford Neal <radf...@cs.toronto.edu> wrote:
> > > But isn't the intent to make it an error later? So I assume we're > > > debating making it an error, not just a warning. > > > > Yes, that's correct. > > But if we have a longish deprecation period (i.e. where there's > > only a warning) all important code should have been adapted > > before it turns to an error > > That might be true for continuously-used code. But for old scripts > for analysing some dataset that someone decides to run again five > years from now, they will be reduced to trying to guess which version > of R they ran under originally, In the general case this is true of any packages they use anyway, though. And if you go back far enough old package versions can't even be installed for current versions of R. Results are always contingent on the software, including versions, used to generate them imho. There are ways to try to address this, but they can be painful and generally require extra work the author of any 5 year old script you have in your hands now likely didn't do. > or if they now want to use newer > features, to doing a binary search for the most recent version of R > for which they still work, or of course going through the script > trying to find the problem. > Now you're talking not about running a script, though, but of maintaining and developing it. I know from personal experience how painful developing on top of legacy code can be, but nonetheless sometimes It needs to be maintained and updated. If you really want absolute safety, that is (more or less) possible, but it means staying in an old version of R with old package versions. I don't think the expectation of being guaranteed to be able to use new features and unmodified legacy code at the same time is reasonable. It's great what that does happen, but it's a bonus imho, not a requirement. Best, ~G > > This wouldn't be a disaster, but I'm not seeing the magnitude of > benefit that would justify imposing this burden on users. A language > specification shouldn't really be changing all the time for no > particular reason. > > Radford Neal > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
