Frequent releases of packages?

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 :sweat_smile:

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?
4 Likes

For now, I would recommend just tagging a release when you need to. Indeed it relies on the work of kind volunteers, but it will be automated soon.

1 Like

Thanks, alright. I am not sure how I could not find those two issues :laughing:

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.

https://cran.r-project.org/web/packages/policies.html#Submission

1 Like

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.

1 Like

I think at most one per month is implied there (just not made explicit).

I think that one can play this by ear, but making a habit of multiple releases per day is not something one should do.

1 Like

I’m just saying that’s how I view it, to be respectful of other people’s time. I’m far less frequent than one month.

Yeah we’ll have automerging in the not-so-distant future. I’ll make a Discourse post when it’s live.

2 Likes

I am a advocate for release after every PR
(except of you already have a release pending.)

See my recent blog-post to that effect.

https://white.ucc.asn.au/2019/09/28/Continuous-Delivery-For-Julia-Packages.html

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.

6 Likes

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…