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

[Russell Bainer]

Steve, I'll not have you malign my collaborators like that. :)

Thanks Nitesh for your clear and sensible suggestions. As Steve has surely
had time to speak the name of Webster lake by now, I'll plan to leave
things as-is and will coordinate with him about sparrow's acceptance status
to make sure that gCrisprTools continues to play nice with the final
version.

Best,

-R

On Wed, Aug 25, 2021 at 9:01 AM Steve Lianoglou <slianoglou using gmail.com>
wrote:

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