[R-pkg-devel] What counts as an API change?

Very interesting thread.

Indeed just got one question in relationship with SEMVER and API.
For a given package, does CRAN adapt the control and acceptance processes
according to SEMVER, when submitting a new package  version ?
Any reference material about CRAN control and acceptance processes are
welcome. Haven't found any yet online.

Neonira

Le jeu. 26 sept. 2019 ? 01:24, Hugh Parsonage <hugh.parsonage at gmail.com> a
?crit :

The approach I take is a major version increment is required if it
requires an existing unit test to be changed or if it requires a reverse
dependency to change a unit test.

(With the exception of tests marked explicitly as unstable.)

In my view the test suite is a good way to advertise exactly what
developers can rely on in minor version upgrades.

On Wed, 25 Sep 2019 at 11:52 pm, David Hugh-Jones <
davidhughjones at gmail.com> wrote:

Hi all,

Philosophical question. My package follows semantic versioning (
https://semver.org). Incompatible API changes should trigger a major
version upgrade. OK, but what counts as an incompatible change to an R
API?
Suppose my current function signature is

foo <- function (a, b, c, d)

and the new one is

foo <- function (a, b, c, d, e)

is that compatible? What if I add an argument, but not at the end:

foo <- function (a, b, c, e, d)

That would be incompatible if people have been calling the arguments by
order rather than by name. But sometimes that is unlikely: I doubt if

many

people write

lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,

FALSE)

Should I be strict or relaxed about this?

Cheers,
David

         [[alternative HTML version deleted]]

         [[alternative HTML version deleted]]

	[[alternative HTML version deleted]]