Releasing packages

[thibautjombart]

@emmanuelparadis @jgx65 @zkamvar @KlausVigo
Shall we coordinate for the releases of our packages?
From the most 'low level' (required by a lot of packages) to the high levels:
ape, adegenet, pegas, hierfstat, phangorn, apex
Do I get the order approximately right?

In any case, as CRAN now asks maintainer to also check backward dependencies, we probably need to release everything at the same time no matter which ways dependencies go.

@emmanuelparadis has anything in ape changed? If not, that makes everything easier - too many packages depend on it ;)

So, please amend/edit as needed, and tick if ready to release

• adegenet: only more testing left to do (recompile tutorials)
• pegas:
• hierfstat: a few things to add, students are on holidays next week, I should be able to have something that can be submitted by the end of next week (April 10th)
• phangorn: @KlausVigo I think is ready?
• apex: nearly ready to go; we just need to ammend the doc a bit

[emmanuelparadis]

For ape: I don't think the new features will impact other packages. You can check what has already been included: [http://ape-package.ird.fr/NEWS]. Note: the current version (on CRAN) is 3.2 and the testing version (not on CRAN) is 3.2-0.x (with x = 8 currently).

For pegas: I'm still conducting some tests of the new VCF code (and fixing some bugs...). A few days should be enough.

Should we really submit all packages to CRAN at the same time? We have added quite a few new things everywhere, so if there are problems, it might be tricky to find where they come from. The alternative would be to submit them sequentially, waiting a few days after between two submissions (CRAN used to check all packages every 24 hrs, but that was some years ago when there were less packages than now...) In that case, we may not be so strict on the sequence. It seems the following sequences might be enough:

adegenet > pegas
adegenet > hierfstat
adegenet > apex
phangorn > apex

What do you think?

[thibautjombart]

All right, I confess part of me just want to piss off BR.. ;)
What you say makes sense, but some changes in adegenet only make sense if released with pegas and hierfstat, as I essentially removed functionalities from adegenet to put them in pegas / hierfstat. Really cool that ape is independent of all of this though. So we could:

1. coordinate for: adegenet + pegas + hierfstat
2. release phangorn independently
3. release apex once phangorn is released

Makes sense?

[emmanuelparadis]

Fine for me. I'm still working on pegas now.

[thibautjombart]

Awesome. @KlausVigo any idea when you release the next version of phangorn? apex will follow soon after :)

[zkamvar]

I hate to be a Debbie Downer (yes, Americans do say things like this), but as a user and the maintainer of poppr, which depends on adegenet and imports ape, pegas, and phangorn, I have but one request:

please, please, please check the reverse dependencies even if you don't think other packages will be affected.

---

Case in point: I woke up to an email from Ripley the day after my wedding because an innocuous bug fix in ape had caused one of my functions to fail (I would have ignored it, but that was also the day after my paper was published). I was lucky because I was able to quickly find a kludge to fix it and @emmanuelparadis was benevolent enough to release a new version of ape soon after.

---

One of the benefits of alerting the other maintainers of dependency issues is that they will find bugs for you. All you have to do is tell them that their package failed under the new version.

Devtools has a function that will check reverse dependencies, imports, and suggests called revdep_check(). Here are all of the reverse dependencies for the packages in descending order:

> revdep("ape", dependencies = c("Depends", "Imports"))
  [1] "adegenet"       "adephylo"       "adhoc"          "apTreeshape"    "BAMMtools"     
  [6] "bayou"          "betapart"       "BioGeoBEARS"    "BoSSA"          "caper"         
 [11] "cati"           "coalescentMCMC" "convevol"       "corHMM"         "DAMOCLES"      
 [16] "DDD"            "DiscML"         "distory"        "diversitree"    "ecospat"       
 [21] "evobiR"         "expands"        "expoTree"       "FD"             "gamclass"      
 [26] "geiger"         "geomorph"       "GrammR"         "graphscan"      "GUniFrac"      
 [31] "HAP.ROR"        "hisse"          "HMPTrees"       "homals"         "HyPhy"         
 [36] "ips"            "iteRates"       "kdetrees"       "laser"          "lefse"         
 [41] "MCMCglmm"       "megaptera"      "Momocs"         "MPSEM"          "msap"          
 [46] "mvMORPH"        "mvSLOUCH"       "nLTT"           "nodiv"          "outbreaker"    
 [51] "OutbreakTools"  "OUwie"          "P2C2M"          "paleotree"      "pastis"        
 [56] "PBD"            "PCPS"           "pcrcoal"        "pegas"          "pez"           
 [61] "phangorn"       "phyclust"       "phylobase"      "phyloclim"      "phylocurve"    
 [66] "phyloland"      "phylolm"        "phylosim"       "phylotools"     "phyloTop"      
 [71] "phytools"       "picante"        "PIGShift"       "poppr"          "primerTree"    
 [76] "PVR"            "RADami"         "RAM"            "rdryad"         "recluster"     
 [81] "Reol"           "rmetasim"       "rncl"           "RNeXML"         "RPANDA"        
 [86] "Rphylip"        "Rsampletrees"   "SeqFeatR"       "sharpshootR"    "sidier"        
 [91] "spider"         "strap"          "strataG"        "stylo"          "surface"       
 [96] "taxize"         "TESS"           "treebase"       "TreePar"        "TreeSim"       
[101] "windex"   

> revdep("adegenet", dependencies = c("Depends", "Imports"))
[1] "adephylo"     "AFLPsim"      "EcoGenetics"  "mmod"         "outbreaker"   "pegas"       
[7] "PopGenReport" "poppr"        "StAMPP"   

> revdep("pegas", dependencies = c("Depends", "Imports"))
[1] "mmod"         "PopGenReport" "poppr"        "spider"       "StAMPP"       "strataG"    

> revdep("hierfstat", dependencies = c("Depends", "Imports"))
[1] "EcoGenetics"

> revdep("phangorn", dependencies = c("Depends", "Imports"))
[1] "coalescentMCMC" "corHMM"         "OUwie"          "paleotree"      "phytools"      
[6] "poppr"          "RADami"         "recluster"      "SeqFeatR"      

Additionally, regarding the submission of packages in order, Uwe Ligges (the windows maintainer) had some advice for people in 2013:

... or ask the CRAN people directly. They will tell you to go ahead,
submit A and mention in the submission mail that the Suggested B which
Depends on A will be uploaded once A has been accepted.

I'm sorry to be a drag on this, but I believe this is important not only for the maintainers, but for the users who depend on these packages to all work together.

[KlausVigo]

I will try to submit this week, tomorrow, more likely Friday. Added a fast
read.FASTA.AA 99% Emmanuel's code. Also phangorn should now finally
estimate the branch length of large trees (rearrangements are coming soon),
which makes George happy.
Does anybody have a recent R-devel on Linux and OSX for running some R CMD
check?
Cheers,
Klaus

On Wed, Apr 1, 2015 at 9:57 AM, Thibaut Jombart [email protected]
wrote:

Awesome. @KlausVigo https://github.com/KlausVigo any idea when you
release the next version of phangorn? apex will follow soon after :)

Reply to this email directly or view it on GitHub
#19 (comment)
.

Klaus Schliep
Postdoctoral Fellow
Revell Lab, University of Massachusetts Boston

[emmanuelparadis]

@zkamvar: I agree with your point. For ape, we set up a protocol before submitting to CRAN: all reverse dependencies are downloaded from CRAN and checked using this "frozen" version of ape (thanks to the effort of our local IT team). I also make a testing version of ape available before it is on CRAN, so other developers have the opportunity to try it.