develop consistent scheme for code tags across packages?

[iantaylor-NOAA]

As we work to align our various R packages within pfmc-assessments it would be nice to develop a tagging convention that can apply across all the packages, so that our future selves will know that the package associated with the "July2023" tag (or whatever) for {nwfscSurvey} will work with the same tag for the {PacFIN.Utilities} and those things will work with the data that we processed for this year's assessments.

Thanks @chantelwetzel-noaa for inspiration to post this.

[kellijohnson-NOAA]

Do we want to use tags in conjunction with a docker file that can be used to install everything that you would need at that point? Tags are only so helpful if users do not know how to install everything and all the dependencies given those tags.

Also, what would be the purpose of wanting to install things back from July of 2022 for example? Is it to reproduce old assessments? I am torn if it is better to be able to install things or have a set of tests that new code must be able to produce similar results, which I am terrible about actually implementing in practice. I guess this would be two entirely different topics ... one for developers and one for users maybe where both are probably needed? P.S. sorry for the rambling.

[okenk]

I have had to install old versions of packages before using github commits and would have welcomed a tag. A package was changed in a way that did not ensure back compatibility because they did not anticipate my use case, and I was about to submit a manuscript.

I think you are right in an ideal world we would have a set of tests for new code, but the reality is you just cannot foresee everything (especially since we are not full-time developers), and sometimes people are going to want to install old versions that work. This is ok.

I do think that is a fair point, if you don't know the version that is installed, the github tag is of no use. On the other hand, it is pretty easy to add the installation line to the top of your scripts, and specifying a tag in install_github() is also pretty easy. (This is what I did in the above example, which was useful because I updated R before I got the paper reviews back.)

[kellijohnson-NOAA]

@chantelwetzel-noaa are you ready for {nwfscSurvey} to become a monster package that way we do not have to worry about creating so many tags and ensuring that everything plays nice. I would actually vote for one package to download stuff and one to run analyses.

[chantelwetzel-noaa]

I mentioned to @iantaylor-NOAA that we (meaning primarily myself) needs to be better about creating tags or version control to assist in people in creating old data processing if needed. However, based on @kellijohnson-NOAA comment I regret opening my big mouth! In all serious I do see the benefit of streamlining since it would increase the probability of versions and/or tags being applied (easier to do it once than to do it across multiple packages). I am open to any future package changes that the team thinks beneficial.