[Bioc-devel] Best practices for joint release/update of BioC packages
@||@nog|ou @end|ng |rom gm@||@com
Wed Aug 25 18:01:30 CEST 2021
I'm the derelict collaborator :-)
I'll be submitting my package faster than you can (correctly) pronounce
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]]
More information about the Bioc-devel