Hello all, I have a question or two about the best ways to go about transferring an R package to a new org and how to best deal with what might be some significant user-visible changes.
I maintain the R package
dplR and have done so for over a decade. It’s pretty widely used in the analysis of tree-ring data. As part of a larger effort to make several different tools available to the research community under one umbrella I’m now part of a team (
OpenDendro) that will have
dplR at its core. I’ll be working with some grownup programmers (not hacks like me!) and we are going to be refactoring the code and streamlining some of the functionality (e.g., make the workflow play nicely with the
tidyverse). This will mean adding some new functions and deprecating some others (e.g., my terrible plotting functions which seemed like a good idea in 2007 have got to go). Over the next two years, we are also going to expand the codebase to include a Python version, some nifty Shiny apps, and much better documentation.
I know I can transfer the ownership of the repo in GitHub easily enough and change the DESCRIPTION in the next release so that the CRAN gods will be placated with a new repo URL. However there will be, I think, some changes that will affect existing users and I’m not eager to break anybody’s code.
I’d like to keep the package name the same (
dplR) regardless of the changes and I’m wondering if it would be wise to make the existing package something like
dplR_Legacy so that longtime users can still have an actively maintained package that works as they are expecting.
I hope that makes sense.
So, here are my questions:
What the best approach is for transferring the existing package to this new organization? Just do it in GitHub under Settings/DangerZone?
Should I create a legacy package on CRAN for existing users that might not want any changes? Or is it better to do something similar like create a legacy branch in Github and not publish it on CRAN?
Any help under the general heading of “what to do when you are thinking about making substantial changes to an existing package but want to keep users happy” would be greatly appreciated. As you can tell, I’m not up to speed on what the best practices are in software development and I’d like to do it right.
Thanks for reading this far.