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

[Steve Lianoglou]

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.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 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]]