|
From: | Gábor Csárdi |
Subject: | Re: [igraph] Version 0.7? |
Date: | Tue, 28 Jan 2014 22:19:55 -0500 |
Hi Gabor,
If I understand correctly from your email, the problem is that many
packages depend on igraph, and so pushing changes to CRAN that disrupt
the API may make a lot of packages to fail to build, potentially
creating a lot of disruption.
My opinion is that yes, usually changing the API or making other big
changes will cause problems. A potential solution is to add a
dependency on a particular igraph version (e.g. igraph <= 0.6). But
this will not solve the problem if the user has other packages that
were updated to use igraph 0.7, as it is not straightforward to
have/maintain both versions of the package in a single installation
(AFAIK).
This problem will still exists if you remove igraph from CRAN, as
different maintainers will adopt igraph 0.7 or future versions at
different paces. It will only make slightly more painful to install
packages that depend on future versions of igraph.
A better solution is actually what you did when igraph 0.6 came out
and changed the index system in R. You released igraph0, which was
actually 0.5, to support legacy code. This required a small change in
the dependencies that most people were probably willing to do at any
time.
The main problem with CRAN is that, unlike Bioconductor, there is no
such a concept of "CRAN releases". In CRAN the latest version of a
package is available irrespective of whether that breaks all the
dependent packages. In Bioc, each release ensures that a particular
version of a package works with a particular version of a dependency.
Of course, this only applies to packages in the Bioconductor
environment.
In summary, I do not think moving igraph from CRAN will solve the
problem. If the new code disrupts a considerable amount of packages
then using the igraph0 approach may be a much useful way to make the
transition smoothly for package maintainers.
[Prev in Thread] | Current Thread | [Next in Thread] |