Steve, I'll not have you malign my collaborators like that. :) Thanks Nitesh for your clear and sensible suggestions. As Steve has surely had time to speak the name of Webster lake by now, I'll plan to leave things as-is and will coordinate with him about sparrow's acceptance status to make sure that gCrisprTools continues to play nice with the final version.
Best, -R On Wed, Aug 25, 2021 at 9:01 AM Steve Lianoglou <slianog...@gmail.com> wrote: > 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
