[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
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
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
> 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>
> > Hello All,
> > I am planning a major update to my BioC package in the next release
> > (
> > and some of the new functionality depends on another package that is
> > 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
> > 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
[[alternative HTML version deleted]]
Bioc-devel using r-project.org mailing list
More information about the Bioc-devel