Hello friends, I'm the derelict collaborator :-)
I'll be submitting my package faster than you can (correctly) pronounce Lake Chargoggagoggmanchauggagoggchaubunagungamaugg https://en.wikipedia.org/wiki/Lake_Chaubunagungamaug -steve On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga <nturaga.b...@gmail.com> wrote: > Hi Russell, > > The deprecation usually occurs around the time of release (October 2021, > but I don't have an exact date yet). > > If your collaborator has submitted the package to Bioconductor or CRAN, > and it gets accepted, and you can make everything build and check cleanly > before the release time, I think you should be ok. It might mean that he > submits the package 'sparrow' soon for review. > > The best way to do this (IMHO) is, wait for your collaborator's code to > get into Bioconductor/CRAN and plan the major release around that. If it > happens after this release, then do a major version update for the next > release cycle (April 2022 - approx). This will add all the significant > updates in your package only in the major version update to 2.0.0. In the > meantime, you may consider fixing/hiding parts of the code why are failing > for October 2021 release. > > Another "non-traditional" way is to add your collaborator as an Author on > your package and ingest parts that improve your package significantly as > code within your package. So this will attribute the authorship of the code > to your collaborator appropriately. Of course, this will not allow for > modular and independent development of two separate packages adding a lot > of complexity. (We should not consider this method for the sake of good > software engineering practices) > > I’m hoping other members on the team / community can provide better > suggestions. > > Best, > > > Nitesh Turaga > Scientist II, Department of Data Science, > Bioconductor Core Team Member > Dana Farber Cancer Institute > > > On Aug 24, 2021, at 7:07 PM, Russell Bainer <russ.bai...@gmail.com> > wrote: > > > > Hello All, > > > > I am planning a major update to my BioC package in the next release ( > > > https://www.bioconductor.org/packages/release/bioc/html/gCrisprTools.html > ), > > and some of the new functionality depends on another package that is > being > > submitted for acceptance by a collaborator. > > > > All of the code in my package passes R/BioC check using the package in my > > collaborator's github repo, but as his code has not yet been incorporated > > into BioC my current build is failing. > > > > What is the recommended way to deal with a situation like this? > Obviously I > > want to avoid deprecation of my own package, and obviously I could just > > hide all of the parts of the update that depend on external code. But I > > also think that my collaborator's work adds significantly to the utility > of > > my package, and I want to ensure that their contributions are properly > > highlighted/celebrated in my 2.0 release. > > > > Thanks in advance for the input. > > > > -R > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > Bioc-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
