Webster lake. Has it been submitted yet? ;-D -----Original Message----- From: Bioc-devel <bioc-devel-boun...@r-project.org> On Behalf Of Steve Lianoglou Sent: Wednesday, August 25, 2021 12:02 PM To: Nitesh Turaga <nturaga.b...@gmail.com> Cc: Russell Bainer <russ.bai...@gmail.com>; Hervé Pagès <bioc-devel@r-project.org> Subject: Re: [Bioc-devel] Best practices for joint release/update of BioC packages
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.h > tml > ), > > 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 _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
