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