Michael Friendly
2020-Jan-08 15:06 UTC
[Rd] re-submission of package after CRAN-pretest notes
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. -Michael -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. & Chair, ASA Statistical Graphics Section York University Voice: 416 736-2100 x66249 4700 Keele Street Web: http://www.datavis.ca | @datavisFriendly Toronto, ONT M3J 1P3 CANADA
Dirk Eddelbuettel
2020-Jan-08 15:09 UTC
[Rd] re-submission of package after CRAN-pretest notes
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 | edd at debian.org
Gabriel Becker
2020-Jan-08 20:28 UTC
[Rd] re-submission of package after CRAN-pretest notes
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 <edd at debian.org> 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 | edd at debian.org > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]