On 26/09/2019 4:22 a.m., neonira Arinoem wrote:
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
> 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
No "maybe" about it.
On September 25, 2019 2:28:27 PM PDT, David Hugh-Jones
wrote:
>Thanks Jeff. My function is currently:
>
>insert_column <- function (ht, ..., after = 0, copy_cell_props = TRUE)
>
>and I want to add a `fill` argument:
>
>insert_column <- function (ht, ..., after = 0, fill =
Thanks Jeff. My function is currently:
insert_column <- function (ht, ..., after = 0, copy_cell_props = TRUE)
and I want to add a `fill` argument:
insert_column <- function (ht, ..., after = 0, fill = NULL, copy_cell_props
= TRUE)
This is definitely the best place for the fill argument - I
"assume default values are provided."
Ah, no. Choosing to specify or not specify default values is a critical step.
As is deciding where any ... argument will be placed (all specific arguments
after that have to be named when called so positional compatibility cannot come
back to bite you).
Both of your examples are incompatible.
foo <- function (a, b, c, d, e = NA )
(add with default value) would be compatible.
Your second example cannot be made compatible even with default values because
the positional behaviour has changed.
On September 25, 2019 6:51:58 AM PDT, David
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
