Re: [Bioc-devel] Best practices for joint release/update of BioC packages
Webster lake. Has it been submitted yet? ;-D -Original Message- From: Bioc-devel On Behalf Of Steve Lianoglou Sent: Wednesday, August 25, 2021 12:02 PM To: Nitesh Turaga Cc: Russell Bainer ; Hervé Pagès 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 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 > 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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Best practices for joint release/update of BioC packages
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 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 > 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 >> 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@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
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 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 > 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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Best practices for joint release/update of BioC packages
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 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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Best practices for joint release/update of BioC packages
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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
