[Bioc-devel] Best practices for joint release/update of BioC packages

James W. MacDonald jm@cdon @end|ng |rom uw@edu
Wed Aug 25 18:34:11 CEST 2021

Webster lake. Has it been submitted yet? ;-D

-----Original Message-----
From: Bioc-devel <bioc-devel-bounces using r-project.org> On Behalf Of Steve Lianoglou
Sent: Wednesday, August 25, 2021 12:02 PM
To: Nitesh Turaga <nturaga.bioc using gmail.com>
Cc: Russell Bainer <russ.bainer using gmail.com>; Hervé Pagès <bioc-devel using 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


On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga <nturaga.bioc using gmail.com>

> 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.bainer using 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 using r-project.org mailing list 
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

	[[alternative HTML version deleted]]

Bioc-devel using r-project.org mailing list

More information about the Bioc-devel mailing list