Hi Diego, I am sorry, I forgot to update the NEWS file in the R package, and there is nothing on the web page yet, so I agree this is not nice at all. Here is the list of changes, I'll also put them on the web page soon: https://github.com/igraph/igraph/blob/release-0.7/www/_posts/2013-11-13-igraph-0.7-r.markdown
Best, Gabor On Thu, Feb 13, 2014 at 11:49 PM, Diego Diez <[email protected]> wrote: > Hi Gabor, > > I have noticed that igraph 0.7 has hit CRAN. Congratulations! > > Also noticed some of the incompatibilities you have mentioned before. > In particular two affecting my package were: > > - the removal of igraph.intersection.by.name() and > igraph.union.by.name(). I found that everything can be done with > igraph.intersection() and igraph.union() and they will guess the right > thing to do. > - before, doing V(g)[ 1 ]$pie.color would return a vector, now it > returns a list() with one element. > > I could find and fix those due to some warnings in the R CMD check > command, but I am wondering if there are other changes that are not > shown there that we should be aware of. I could not find the list of > changes in the NEWS file. Is there a place where the changes in igraph > 0.7 can be checked? > > Thank you. > Best regards, > Diego > > On Fri, Jan 31, 2014 at 12:52 AM, Gábor Csárdi <[email protected]> > wrote: > > On Wed, Jan 29, 2014 at 10:10 PM, Diego Diez <[email protected]> > wrote: > >> > >> On Wed, Jan 29, 2014 at 12:19 PM, Gábor Csárdi <[email protected]> > >> wrote: > > > > [...] > >> > >> > I think the current CRAN organization is unsustainable, and makes > >> > maintainers with popular packages work a lot. This should be avoided, > >> > and my > >> > problem is that I don't see any improvement or developments towards > >> > this. > >> > >> Do you really need to check all dependent packages in CRAN by > >> yourself? I am ignorant about CRAN rules as I never submitted there, > >> mainly because all my packages fit better in the Bioconductor > >> environment. But it looks unreasonable to put that burden on the > >> developers. Maintainers of dependent packages should either adapt the > >> package or require a specific version of the package (with all the > >> limitations this has). > > > > > > Yes, I do. I asked them explicitly, and they told me that on a four core > > machine it only takes a couple of hours, or something like that. > > > >> > Yes, that is exactly the problem. I am thinking about working around > >> > this, > >> > e.g. by having an igraph_installer package on CRAN, that would be able > >> > to > >> > install and load multiple versions of igraph. This way people could > >> > depend > >> > on exact versions. But I still need to work this out fully, in a way > >> > that it > >> > potentially acceptable for the CRAN maintainers, and convenient for > >> > people > >> > who use igraph. > >> > >> Another possibility is using github and then people can use devtools' > >> install_github() to get any version they want. This is becoming so > >> popular that probably it is worth trying. Today in Bioconductor they > >> announced a bioc-github bridge and I am looking forward to move all my > >> development there. > > > > > > igraph is on github, but I don't like installing packages from github, > > because I want to provide binaries for windows and osx users. So if not > > CRAN, then I would create a CRAN-like repository people can install from, > > simply with install.packages(). > > > >> I just read the thread in R-devel where you were asking for advice > >> about making the transition with igraph 0.6. I guess the main problem > >> is that they did not like the idea of igraph0, but preferred that you > >> have left igraph as it was and created igraph2. Indeed that would have > >> been even better in terms of the end users as no packages would have > >> been disrupted at all. Then adding a warning in igraph about igraph2 > >> being released would make users/package maintainers aware of the new > >> version. I understand that maybe you did not want to change the name > >> of the package for consistency with the other igraph APIs. In my > >> personal case I only use the R interface, so whether the other > >> interfaces have different version numbers or not is completely > >> irrelevant- as far as I have the latest R version. > > > > > > I think changing the name of the project every time there is an > incompatible > > update is absurd. The problem is clearly the lack of versioned > dependencies > > and installs, and renaming is a big hack, imho. What I did was a hack, > too, > > but on the long run it was better, I think. > > > > [...] > > > >> Actually, I was tempted to suggest that directly. The reason I did not > >> do so is that igraph is way a more general package in terms of > >> audience. Many people working on things unrelated to biology may find > >> it more difficult to access the latest version of igraph if it is in > >> bioconductor. (maybe not?). After all, and as you said, package > >> versioning will be controlled there. That is not so different to > >> making a new package called igraph2! > > > > > > It is actually easy to install from BioC, you just need to set the > > repository in your startup file, or explicitly in install.packages(). It > is > > 20 more characters to type, that is true. So this is not really like > > igraph2. > > > > I could try to negotiate the BioC people about version numbers, > obviously I > > don't want to change the igraph version numbers. > > > > Anyway, I don't think anything will happen soon and igraph will be on > CRAN > > for a while. > > > > Best, > > Gabor > > > > _______________________________________________ > > igraph-help mailing list > > [email protected] > > https://lists.nongnu.org/mailman/listinfo/igraph-help > > > > _______________________________________________ > igraph-help mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/igraph-help >
_______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
