Gábor Csárdi
2011-Oct-19 18:05 UTC
[Rd] RFC: 'igraph' package update and backward compatibility
Dear R developers, I am seeking advice on some $subject matter. My package will have an update soon, that is not backward compatible with the current version. It will likely break much of the existing code. Many (~50) packages depend on 'igraph' and they, too, will most probably break with the new version. My intended solution is, that I create a snapshot of the current package, under another name (igraph0), and ask package maintainers to depend on that version. Then, after a short time, I'll update the current igraph version. Do you see any drawbacks of this solution? Is there some existing practice for situations like this? Suggestions are greatly appreciated. Btw. an alternative would be to ask them to depend on the exact current version of the package. This is an easier solution, but it won't give people the opportunity to load both versions of the package at the same time, if they want to run their old code. Thank You, Best Regards, Gabor -- Gabor Csardi <csardi.gabor at gmail.com> Dept. Statistics, Harvard University
Rainer M Krug
2011-Oct-20 07:21 UTC
[Rd] RFC: 'igraph' package update and backward compatibility
On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi <csardi@rmki.kfki.hu> wrote:> Dear R developers, > > I am seeking advice on some $subject matter. > > My package will have an update soon, that is not backward compatible > with the current version. It will likely break much of the existing > code. Many (~50) packages depend on 'igraph' and they, too, will most > probably break with the new version. >Don't forget the indirect dependencies - might be many more. One approach used by e.g. ggplot and roxygen, is to call the new package ggplot2 or roxygen2. This would not break old packages.> My intended solution is, that I create a snapshot of the current > package, under another name (igraph0), and ask package maintainers to > depend on that version. Then, after a short time, I'll update the > current igraph version. >I would rather give the new one a a new name by appending the 2> Do you see any drawbacks of this solution? Is there some existing > practice for situations like this? Suggestions are greatly > appreciated. >Well - they require immediate action by the package maintainers. Yo could put a warning in the original iplot package, that the package is not updated any more and that a switch to iplot 2 is suggested. So no immediate action by the package maintainers is required. Cheers, Rainer> Btw. an alternative would be to ask them to depend on the exact > current version of the package. This is an easier solution, but it > won't give people the opportunity to load both versions of the package > at the same time, if they want to run their old code. > > Thank You, Best Regards, > Gabor > > -- > Gabor Csardi <csardi.gabor@gmail.com> Dept. Statistics, Harvard University > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug [[alternative HTML version deleted]]
Gábor Csárdi
2011-Oct-20 11:21 UTC
[Rd] RFC: 'igraph' package update and backward compatibility
Thanks for the insight! It is indeed true that naming the new version 'igraph1' (this is a better name for the change it introduces), is optimal for the existing packages. I was a bit reluctant to do this, because of two reasons. First, igraph exists as a Python package, and a C library as well, and I was afraid that it would cause confusion for users to have different names for the different packages. I can already see the emails with people asking questions about the difference between Python igraph and R igraph1 and whether igraph1 is available for Python, etc. The second reason was that I want users to use the newer version of the package; I was afraid that most them would probably not notice that there is a new version under a different name. But this issue is neatly solved by a warning in the old package, as Rainer suggested. Hmmmm, it is a hard decision. I think I'll just write an email to the maintainers of the packages in question and see how many of them responds. Maybe breaking a couple of unmaintained packages is not a huge tragedy. But of course I can see the burden for CRAN maintainers and don't want to exploit them. Thank you, Gabor On Thu, Oct 20, 2011 at 3:27 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:> We've had examples of that approach (e.g. mclust02) and also of packages > becoming foo2 (e.g. ggplot2). > > The problem is > >> ask package maintainers to depend on that version. > > In our experience that takes years to achieve! ?I think that any solution > which requires the maintainers of 50 others to submit new versions is going > to cause a lot of work for the CRAN crew and not be very comprehensive. > > I do prefer the igraph2 route. ?But you also need to be aware that would > need igraph to be maintained for a long time to come: our experience with > e.g. ncdf/ncdf4 is that the maintainers simply do not change. ?(In the case > of ggplot, the author did not even migrate his own dependent packages!) > > I think you should assume that a high proportion of packages are not > actively maintained. > > Cc:ed to CRAN, since it is really Kurt's place to advise you what CRAN would > like. > > Brian Ripley > > On Wed, 19 Oct 2011, G?bor Cs?rdi wrote: > >> Dear R developers, >> >> I am seeking advice on some $subject matter. >> >> My package will have an update soon, that is not backward compatible >> with the current version. It will likely break much of the existing >> code. Many (~50) packages depend on 'igraph' and they, too, ?will most >> probably break with the new version. >> >> My intended solution is, that I create a snapshot of the current >> package, under another name (igraph0), and ask package maintainers to >> depend on that version. Then, after a short time, I'll update the >> current igraph version. >> >> Do you see any drawbacks of this solution? Is there some existing >> practice for situations like this? Suggestions are greatly >> appreciated. >> >> Btw. an alternative would be to ask them to depend on the exact >> current version of the package. This is an easier solution, but it >> won't give people the opportunity to load both versions of the package >> at the same time, if they want to run their old code. >> >> Thank You, Best Regards, >> Gabor >> >> -- >> Gabor Csardi <csardi.gabor at gmail.com> Dept. Statistics, Harvard University >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, ? ? ? ? ? ? ? ? ?ripley at stats.ox.ac.uk > Professor of Applied Statistics, ?http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, ? ? ? ? ? ? Tel: ?+44 1865 272861 (self) > 1 South Parks Road, ? ? ? ? ? ? ? ? ? ? +44 1865 272866 (PA) > Oxford OX1 3TG, UK ? ? ? ? ? ? ? ?Fax: ?+44 1865 272595-- Gabor Csardi <csardi at rmki.kfki.hu>? ?? MTA KFKI RMKI
Hadley Wickham
2011-Oct-20 14:56 UTC
[Rd] RFC: 'igraph' package update and backward compatibility
> My package will have an update soon, that is not backward compatible > with the current version. It will likely break much of the existing > code. Many (~50) packages depend on 'igraph' and they, too, ?will most > probably break with the new version. > > My intended solution is, that I create a snapshot of the current > package, under another name (igraph0), and ask package maintainers to > depend on that version. Then, after a short time, I'll update the > current igraph version.The optimal solution would be if R packages could depend on a specific version of a package, and a user could have multiple packages installed, and different versions loaded simultaneously so that different packages could depend on different versions. This is what (e.g.) ruby gems do. Unfortunately this is a hard problem to solve - namespaces go some way to help, but I think there are still outstanding S3 and S4 issues. My work around of renaming packages after API breaking changes is definitely a sub-optimal fix. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/