[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
https://en.wikipedia.org/wiki/Lake_Chaubunagungamaug
-steve
On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga <nturaga.bioc using 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.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
https://stat.ethz.ch/mailman/listinfo/bioc-devel
More information about the Bioc-devel
mailing list