Release cadence: How do developers estimate when a new release is due?

Package Development
#1

How do developers estimate when a new release is due?

  • When enough new features & bug fixes have accumulated in the development version. It’s the strategy I was using until now but it’s still somewhat vague. How do you determine when is this “enough”? Does anyone follow an objective rule for this?

  • Releases on a regular schedule (strategy of, e.g., R, Ubuntu, Firefox). All the projects I can think of for this strategy are very active projects with paid developers. This might indicate it’s better suited for this kind of project(???)

  • Whenever the maintainer has enough time to go through with the release process. I suspect this is a quite common approach but it is more based on constraints independent from the software and might not be what is “best” for the package.

I think this question becomes more pressing in the case of a low activity packages. With the 1st strategy, you run the risk of keeping features & bug fixes in the dev branch for a long time. But with the 2nd strategy, you produce of lot of small versions with few changes.

How do other developers estimate when a new release is due? Do you have tips or strategy to determine when the time is right?

1 Like
#2

I try to release new version on CRAN or Bioconductor when there are enough modifications that make it relevant for the end users. If you work on the package from time to time and don’t have enough modifications to make it worthy to users do not release a new version (users will still be able to use the development version of the package if they wish a specific feature still not released). What is worth to users is hard to decide, but if there is a big bug fix or a speed increase (and the package benefits from it) it is highly desirable to end users (and of course if there is a new feature).

I think the regular schedule makes more sense were the project has consistent modifications and the number of users is high (usually not the case for R packages). If the package is on Bioconductor there is a regular release even if the package is not modified at all (the version number is increased on the release process).

Best for the package and best for the maintainer is usually highly relevant. Starting a CRAN submission process and leaving it unattended could have unintended consequences. On Bioconductor and rOpenSci this could happen too, but these archives are usually more tolerant to pausing (first-time) submissions.

2 Likes
#3

Having a package that’s been established on CRAN for almost 9 years (coming up in five weeks), I’ve found the first strategy to be the most straightforward, except the determination of “enough” bugfixes or new features is “one or more” because any new feature/bugfix is of value and they happen rarely in the package’s old age.

I have seen (and participated in) packages that do not update for as much as two years even though new features and serious bug fixes accumulate in the development version because the process for submitting to CRAN is too arduous. I don’t think this is the right strategy because the longer you stay out of the CRAN pipeline, the harder it is to get something submitted when you really need to.

2 Likes
#4
  1. When a dependency causes the package to break; you hope for early notice of this, but try to fix right away so as not to hold up another package (and keep users happy) or R itself.
  2. When there are a decent number of bug fixes or even just one if it is a problem for a user and we haven’t released in a while.
  3. After what is essentially a sprint of getting a new feature done or some substantial refactoring.
3 Likes