search

tidyverse / style

The tidyverse style guide for R code
https://style.tidyverse.org
Other
298 stars 104 forks source link

Should breaking changes have a major version bump? #171

Closed lorenzwalthert closed 3 years ago

lorenzwalthert commented 3 years ago

Under 10.2.3, breaking changes in the context of NEWS.md are discussed. However, it's not stated explicitly that breaking changes require a bump of the major version (e.g. from 1.3.2 to 2.0.0). It's also not explicitly recommended in r-pkgs (maybe this issue should rather go there), although semantic versioning is mentioned there. But I think at least for {dplyr} and some other tidyverse packages, I think the convention is to bump the major for breaking changes. Should this be formalised somewhere? I.e. add a sentence here in

If there are API breaking changes (as discovered during revdepchecks) these should also appear in their own section at the top. Each bullet should include a description of the symptoms of the change, and what is needed to fix it. The bullet should also be repeated in the appropriate section.

of in r-pkgs.org, e.g. here:

Increment the development version, e.g. from 9000 to 9001 if you’ve added an important feature that another development package needs to depend on.

Seems to me that how to handle breaking changes in releases is merits more mention than how to increase the dev part of the version when adding new features.

hadley commented 3 years ago

It all depends on the severity of the breaking change — it's quite possible for something that is technically breaking change to not affect any user code. So I don't think there are any absolute rules, but if you do expect a change to break a lot of existing code it should be major version.

But generally, I don't think the style guide is quite the right place for this sort of nuanced discussion. Might be better in R packages?