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 <rip...@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.ga...@gmail.com> Dept. Statistics, Harvard University >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, rip...@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 <csa...@rmki.kfki.hu> MTA KFKI RMKI ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
