Hi Michael,
At the risk of sounding like I'm just name-dropping, R. Gentleman once told
me something along the lines of "version numbers are cheap, don't be afrai
to use a lot of them".
I get that its a bit annoying but its for good reason, imho. Any change, no
matter how trivial will change the MD5 of the package tarball. And as
someone who has administered a large shared R platform, I don't really ever
want 2 (source) tarballs of the "same version" of a package to differ like
that. Bumping the smallest portion of the version number doesn't seem a
very high price to avoid any possibility of that kind of confusion, to me
at least.
Obviously this only holds for published package versions, installing
directly from source control is a different story all together (which is
why, imho, it is so dangerous and should be avoided whenever its not
absolutely necessary, e.g., developing your own package against dev
versions of other packages). I could go on a lot more about that, but I'll
spare everyone the rant :)
Just my 2c
Best,
~G
On Wed, Jan 8, 2020 at 7:09 AM Dirk Eddelbuettel wrote:
>
> On 8 January 2020 at 10:06, Michael Friendly wrote:
> | It used to be the case that when I submitted a package and it gave notes
> | or warnings in the CRAN checks, I was required to bump the package
> | version before re-submission.
> |
> | I hope this is no longer the case. I recently submitted a package that
> | gave one fairly trivial NOTE, fixed that, and would like to re-submit.
>
> Quoting from the bottom of the current CRAN Repo Policy:
>
>Re-submission
>
> Re-submission is done in the same way as submission, using the
> ‘Optional
> comment’ field on the webform (and not a separate email) to explain
> how
> the feedback on previous submission(s) has been addressed.
>
> Updates to previously-published packages must have an increased
> version.
> Increasing the version number at each submission reduces confusion
> so is
> preferred even when a previous submission was not accepted.
>
> [...]
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
