This kind of a meta question, but related to the package repository. I don’t know where to put it…
I feel a bit reluctant to create frequent releases of my package because I know that the pull requests are manually reviewed and merged, and I tend to think that I have to justify every release because I am creating work for others. It might be just me, but I an automated process (at least after the initial registration of the package) could possibly lower the threshold in general
Two questions:
Am I the only one who thinks like this and should I stop worrying (e.g. not hesitating to submit a “hotfix-release” ten minutes after having created a register request because reasons)?
Why is it done manually after all; is it planned to automate the process in near future?
I’m not one of those maintainers, but I roughly use the CRAN suggestion of (at most) one release per month per package. Obviously, if there’s a critical bug you should put a patch release out as fast as feasible, but for me this feels like a good metric to balance freshness vs. wasting everyone’s time
edit: make it clear that to respect people’s time, release at most once per month, as opposed to sending a new package release every 3 days
Submitting updates should be done responsibly and with respect for the volunteers’ time. Once a package is established (which may take several rounds), “no more than every 1–2 months” seems appropriate.
Hmm, I don’t see why a release should be based on (periodic) time intervals. The version changes just happen when they happen during coding, following SemVer.
The effort for registry maintainers to manually press merge after a quick glance
is much lower than the effort the PR maker is making to add a feature/fix a bug in the package.
So to be respectful of their time, you should tag a release
so they can benifit from the code they wrote.
To me this makes a lot of sense. It’s almost like a reward for the PR. But I have (too rarely) only been on the PR side, never on the reviewing releases side…