Hi Gabor, Thank you so much for the info.
Best, Diego On Fri, Feb 14, 2014 at 11:02 PM, Gábor Csárdi <[email protected]> wrote: > 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 > _______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
