Re: [R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines

[Toby Hocking]

Hi Tomas, these are really helpful suggestions, which are not at all
discussed in the current Writing R Extensions, nor in CRAN Repository
Policy. Would you please consider adding this information to one of these
official sources of documentation?

On Fri, May 14, 2021 at 3:59 AM Tomas Kalibera 
wrote:

>
> On 5/14/21 4:19 AM, SN248 wrote:
> > Thank you Tomas and Sokol for your suggestions.
> >
> > Based on Tomas' suggestion, it seems the best way forward would be to
> > first request CRAN maintainers to install libsbml on the CRAN
> > machines. It is quite straightforward to install the library from the
> > instructions provided online. If the installation fails on a
> > particular architecture, I should try bundling the source code and
> > creating the static libraries.
>
> Please let me clarify, I am not suggesting that you ask CRAN team to
> create the distribution packages for you, but only to install an
> existing distribution package (in case they are not doing that already).
>
> The distribution package is usually a script which automatically
> downloads the software, builds it, picks up the results, adds some
> meta-data about dependencies, and archives them in a supported format.
> Someone has to create the distribution package, and I am suggesting that
> you as R package maintainer should do that, possibly getting help from
> other volunteers e.g even on the R-devel mailing list. The CRAN team
> would only add that package name to their list of installed packages (in
> case it is not there implicitly, i.e. they possibly won't have to do
> anything).
>
> So first, I would should check for existing distribution packages. Most
> distributions have their own indexing/search support, but you can also
> look online as follows.
>
> For Linux distributions, there is e.g. pkgs.org for the first quick
> search (libsml-devel, libsbml-dev might be what you are looking for).
>
> For Windows, msys2 packages are here
> https://github.com/msys2/MINGW-packages/, rtools packages are here
> https://github.com/r-windows/rtools-packages (so there is
> mingw-w64-libsbml). MXE packages are here
> https://github.com/mxe/mxe/tree/master/src and the customized version
> for R is here
>
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/
> (so upstream MXE doesn't have sbml, but the customized has libsbml).
>
> For macOS, recipes for R are here
> https://github.com/R-macos/recipes/tree/master/recipes and it does not
> have sbml library as far as I can see.
>
> So, if you wanted your package to use sbml, the best way would be to
> test it with the sbml package from all the distributions mentioned above
> (from Linux, at least the ones used by CRAN - Debian/Ubuntu, Fedora).
> Then, you would create a recipe (distribution package) for macOS, test
> it with your package, and contribute to the "recipes" above. When
> creating the recipe, look at other recipes to get the form, and look at
> sbml in the previously mentioned distributions to see how to
> download/build it (in addition to the online manual you mentioned).
>
> Once that is in, you could submit your package to CRAN, following the
> usual checks you do when submitting packages. And then, in case it
> failed on some of the CRAN machines, you could contact the individual
> maintainer and ask for installing that distribution package of the given
> name. In some cases it won't be necessary (the machines would already
> have the package, they may be installing all available packages
> automatically).
>
> This may sound like a bit of work, but that is the price for adding
> dependencies on native libraries, and someone has to do this work.
> Installing libraries manually on the check machines is not going to
> scale and may be too much burden for many end users, apart from
> difficulties with repeatability, maintenance, etc.
>
> Best
> Tomas
>
> >
> > Thanks again for your help.
> > Satya
> >
> > On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera
> > mailto:tomas.kalib...@gmail.com>> wrote:
> >
> >
> > On 5/13/21 7:06 AM, SN248 wrote:
> > > I am working on a package which provides an interface to the
> > libsbml C++
> > > library (http://sbml.org/Software/libSBML
> > ) in R. The source code of this
> > > package (r2sbml) can be found at the following link
> > >
> > > https://github.com/sn248/r2sbml 
> > >
> > > The package passes CRAN checks with `R CMD check` on my machine,
> > but I do
> > > have dependency (libsbml library) installed on my machine (OSX)
> with
> > > headers and static libs at the usual locations, i.e.,
> > /usr/local/include
> > > and /usr/local/lib. The package also passes CRAN check on a
> > Windows machine
> > > with libsbml installed using Rtools40 and msys2. The DESCRIPTION
> > file lists
> > > libsbml in SystemRequirements but `R CMD check` obviously fails
> > on 

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

[Toby Hocking]

Thanks Dirk. I agree.
data.table is not in a situation to update very soon, so the easiest
solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
to 2 on the Windows and Debian machines doing this test.
Otherwise the 1400+ packages with hard dependencies on data.table will
each have to implement custom logic to limit threads to 2.
Toby

On Fri, Aug 25, 2023 at 6:46 AM Dirk Eddelbuettel  wrote:
>
>
> On 24 August 2023 at 07:42, Fred Viole wrote:
> | Hi, I am receiving a NOTE upon submission regarding the re-building of
> | vignettes for CPU time for the Debian check.
> |
> | I am unable to find any documented instances or solutions to this issue.
> | The vignettes currently build in 1m 54.3s locally and in 56s on the Win
> | check.
> |
> | 
> https://win-builder.r-project.org/incoming_pretest/NNS_10.1_20230824_132459/Debian/00check.log
>
> Please see, inter alia, the long running thread
>
>"Trouble with long-running tests on CRAN debian server"
>
> started earlier this week (!!) on this list covering exactly this issue.
>
> We can only hope CRAN comes to understand our point that _it_ should set a
> clearly-identifable variable (the OpenMP thread count would do) so that
> package data.table can this for its several hundred users.
>
> As things currently stand, CRAN expects several hundred packages (such as
> your, guessing there this comes from data.table which I do not know for sure
> but you do import it) to make the change which is pretty close to the text
> book definition of madness.
>
> Also see https://github.com/Rdatatable/data.table/issues/5658 with by now 24
> comments.  It is on the same issue.
>
> Uwe, Kurt: Please please please set OMP_THREAD_LIMIT to 2 on the Windows and
> Debian machines doing this test.
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] unregistered S3 methods in a package

[Toby Hocking]

I got this warning too, so I filed an issue to ask
https://github.com/r-lib/roxygen2/issues/1654

On Mon, Sep 2, 2024 at 2:58 PM John Fox  wrote:
>
> As it turned out, I was able to avoid redefining coef.merMod(), etc., by
> making a simple modification to the cv package.
>
> I'm still curious about whether it's OK to have unregistered S3 methods
> for internal use in a package even though that's no longer necessary for
> the cv package.
>
> On 2024-09-02 11:34 a.m., John Fox wrote:
> > Caution: External email.
> >
> >
> > Dear R-package-devel list members,
> >
> > I want to introduce several unregistered S3 methods into the cv package
> > (code at ). These methods have the form
> >
> > coef.merMod <- function(object, ...) lme4::fixef(object)
> >
> > The object is to mask, e.g., lme4:::coef.merMod(), which returns BLUPs
> > rather than fixed effects, internally in the cv package but *not* to
> > mask the lme4 version of the method for users of the cv package -- that
> > could wreak havoc with their work. Doing this substantially simplifies
> > some of the code in the cv package.
> >
> > My question: Is it legitimate to define a method in a package for
> > internal use without registering it?
> >
> > This approach appears to work fine, and R CMD check doesn't complain,
> > although Roxygen does complain that the method isn't "exported"
> > (actually, isn't registered).
> >
> > Any advice or relevant information would be appreciated.
> >
> > Thank you,
> >   John
> > --
> > John Fox, Professor Emeritus
> > McMaster University
> > Hamilton, Ontario, Canada
> > web: https://www.john-fox.ca/
> > --
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] SystemRequirements: Berkeley DB STL

[Toby Hocking]

I would like to put the https://github.com/tdhock/PeakSegDisk package on
CRAN. This package needs Berkeley DB C++ Standard Template Library. What do
I need to do to get this package (with compiled mac/windows binaries) on
CRAN?

This C++ library is relatively easy to install
https://github.com/tdhock/PeakSegPipeline/wiki/FAQ#installing-berkeleydb-stl
but probably too big (tar.gz source code is 43MB) to include in the R
package, so I have indicated this external library dependency in the
SystemRequirements field of DESCRIPTION. I have also put PKG_LIBS=-ldb_stl
in my src/Makevars. Is that OK?

My Linux travis builds pass CRAN checks just fine
https://travis-ci.org/tdhock/PeakSegDisk/jobs/442813478 because I have
installed the libdb5.1-stl-dev package which provides -ldb_stl.

Usually I check my packages on win-builder prior to CRAN submission. When I
check PeakSegDisk on win-builder, I get a linker error (db_stl not found)
because presumbly it is not installed on the win-builder machine. So
presumably my package would not pass checks on CRAN.

I have emailed Uwe Ligges to ask to install BerkeleyDB STL on win-builder
but I have got no response. Is there anybody else I should ask?

Is there anything else I should do?

FYI I believe that I have done my homework. From a search of
"systemrequirements" on r-package-devel I saw that there are several
related threads, for example a message on Feb 4 from Dirk who explains how
to use PKG_LIBS. However I did not see any specific explanation of how to
get a package with dependent compiled code on CRAN. Maybe the officially
accepted method should be added to Writing R Extensions or CRAN Repository
policies?

Thanks in advance for any help/advice you can provide.
Toby Dylan Hocking

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] SystemRequirements: Berkeley DB STL

[Toby Hocking]

Hi Dirk thanks for the helpful response.
On Wed, Oct 24, 2018 at 5:09 AM Dirk Eddelbuettel  wrote:

>
> On 23 October 2018 at 14:02, Toby Hocking wrote:
> | I would like to put the https://github.com/tdhock/PeakSegDisk package on
> | CRAN. This package needs Berkeley DB C++ Standard Template Library. What
> do
> | I need to do to get this package (with compiled mac/windows binaries) on
> | CRAN?
> |
> | This C++ library is relatively easy to install
> |
> https://github.com/tdhock/PeakSegPipeline/wiki/FAQ#installing-berkeleydb-stl
> | but probably too big (tar.gz source code is 43MB) to include in the R
> | package, so I have indicated this external library dependency in the
> | SystemRequirements field of DESCRIPTION. I have also put
> PKG_LIBS=-ldb_stl
> | in my src/Makevars. Is that OK?
>
> In short, no.
>
> This is a messy topic, but in the briefest of nutshells you have an
> external
> library here which needs linking.  That makes it complicated.
>
> A short road map (in increasing order of complexity) about the situation:
>
>
>  - a small external library shipped just as headers, eg catch2, is easiest:
>
>=> just include the header file
>=> maybe even package the header file up in a package so that other
>   packages can use it
>
>
>  - a small external library ie just a few files is doable with little work:
>
>=> just include it in your src/ directory
>=> or maybe one level below src/ and have Makevars build it
>   (which is something I just did to one of my packages)
>
>
>  - a small-to-medium library typically installed externally gets harder
>
>=> you are at the mercy of CRAN to have THAT LIBRARY on ALL of their
> systems
>=> or if you can do the work, install it via your package (nloptr does
> that)
>   (nloptr is extra-special because it then also exports 10 or so C
> entry points)
>
>
>  - a large and complex library is really difficult
>
>=> like the last point, only worse
>
>
> These (three to) four approaches could be split up further, eg by C versus
> C++, or by 'do you want other CRAN packages to use it too or not' etc.
>
> Here, you are at the last point. You have library that is
>   a) large
>   b) reasonably uncommon
>   c) available in some but not other places
>
> As your README states, it exists for Debian/Ubuntu so you could (privately)
> ask Kurt to install it on his machines which he will probably do.  A start.
>

I have emailed Kurt about this.


> But then you still need Windows (where Uwe is generally equally helpful,
> but
> not everything builds on Windows, he has zero spare time to build it for
> you
> and we have no mechanism to get it to him -- or maybe we do via Jeroen's
> rwinlibs -- to be checked). So a possible roadblock.
>

Judging from Uwe's non-response to my email requests, Jeroen's rwinlibs may
be a better option -- but what is that? I am not familiar with rwinlib.
Where are the docs?


>
> And then you need macOS.  I will not say much more in order to remain
> polite
> and civil, but if you check the archives of this list and r-devel you will
> find me _begging_ a few weeks ago to be given a handle to turn off builds
> of
> a package of mine because it could never have its libraries on macOS yet it
> would still always attempt to build on macOS yielding me two ERROR and a
> "bad
> package" stigma.  I still have that problem with a few other packages of
> mine
> lacking a macOS library at CRAN, and it is "difficult" to understate by
> some
> order.
>
I emailed Simon about this and he added to his recipes so hopefully that
will work,
https://github.com/s-u/recipes/commit/b61ee4d82b58f0114475c790f0844f98b918be01


>
> Oh, and did I mention the joy that is Solaris?
>
In theory Solaris should not be hard -- the installation from source is
pretty much a standard configure && make && make install.

curl -OL http://download.oracle.com/berkeley-db/db-6.2.23.NC.tar.gz
tar xf db-6.2.23.NC.tar.gz
cd db-6.2.23.NC/build_unix
../dist/configure --prefix=$HOME --enable-stl
make
make install


BTW in response to Hong: sorry for linking to the wrong wiki page -- in
fact PeakSegDisk does NOT depend on any UCSC tools. Just Berkeley DB STL
C++ library.

>
> In short, this is complicated. See fortunes::fortune(356) (h/t Doug Bates).
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] unicode WARNING on solaris?

[Toby Hocking]

Hi all,

is there a known fix for this WARNING which I am getting on solaris for my
newly submitted nc package?
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html

A quick google search for "it is not known that wchar_t is Unicode on this
platform cran" shows that many other packages have this WARNING as well.

I searched r-devel and r-pkg-devel for the warning text but I did not find
any messages discussing a fix.

Thanks for any help
Toby

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] unicode WARNING on solaris?

[Toby Hocking]

Hi Tomas thanks for the explanation. Does that mean that there is no known
fix? i.e. it is OK to re-submit a new version of my package without fixing
these WARNINGS?

On Tue, Sep 24, 2019 at 1:38 AM Tomas Kalibera 
wrote:

> On 9/24/19 1:57 AM, Toby Hocking wrote:
> > Hi all,
> >
> > is there a known fix for this WARNING which I am getting on solaris for
> my
> > newly submitted nc package?
> >
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
>
> It seems that deparse() came across some non-printable characters. Such
> characters would be replaced by \U or \u escapes. This is implemented
> using wide characters in R, but on that platform __STDC_ISO_10646__ is
> not defined, so wchar_t has unknown representation (not known to be
> Unicode), hence the warning.
>
> Best
> Tomas
>
> >
> > A quick google search for "it is not known that wchar_t is Unicode on
> this
> > platform cran" shows that many other packages have this WARNING as well.
> >
> > I searched r-devel and r-pkg-devel for the warning text but I did not
> find
> > any messages discussing a fix.
> >
> > Thanks for any help
> > Toby
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] unicode WARNING on solaris?

[Toby Hocking]

Right, thanks for the tip.

For future reference: if you want to avoid this warning, but still use
examples with unicode, you can put the unicode text data in
inst/extdata/file_with_unicode.txt and then in your example code you can
read it via

readLines(system.file("extdata", "file_with_unicode.txt",
package="yourPkg"))

On Wed, Sep 25, 2019 at 11:45 AM Tomas Kalibera 
wrote:

> On 9/25/19 7:59 PM, Toby Hocking wrote:
>
> Hi Tomas thanks for the explanation. Does that mean that there is no known
> fix? i.e. it is OK to re-submit a new version of my package without fixing
> these WARNINGS?
>
> One way to fix would be to remove non-ASCII characters from the examples.
> I see \u4e8c \u4e09 \U0001F60E.
> Tomas
>
>
> On Tue, Sep 24, 2019 at 1:38 AM Tomas Kalibera 
> wrote:
>
>> On 9/24/19 1:57 AM, Toby Hocking wrote:
>> > Hi all,
>> >
>> > is there a known fix for this WARNING which I am getting on solaris for
>> my
>> > newly submitted nc package?
>> >
>> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
>>
>> It seems that deparse() came across some non-printable characters. Such
>> characters would be replaced by \U or \u escapes. This is implemented
>> using wide characters in R, but on that platform __STDC_ISO_10646__ is
>> not defined, so wchar_t has unknown representation (not known to be
>> Unicode), hence the warning.
>>
>> Best
>> Tomas
>>
>> >
>> > A quick google search for "it is not known that wchar_t is Unicode on
>> this
>> > platform cran" shows that many other packages have this WARNING as well.
>> >
>> > I searched r-devel and r-pkg-devel for the warning text but I did not
>> find
>> > any messages discussing a fix.
>> >
>> > Thanks for any help
>> > Toby
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] invalid multibyte string on solaris?

[Toby Hocking]

Hi all, I am getting an "invalid multibyte string" error from one of my
examples when it is run on solaris, which results in check FAILURE:
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html

To fix this I guess I could just delete this example, but is there any
easy/known fix? I searched the r-devel and r-package-devel lists and I did
not find any relevant threads.

I also see that the same package on r-hub solaris is a check PASS:
https://builder.r-hub.io/status/nc_2019.10.19.tar.gz-8b46d2a02a6340bcb313eeec96e404f3

I was expecting that CRAN and r-hub solaris builds should report the same
results. What could be the difference? is this a bug in CRAN or in r-hub?

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Help in getting past CRAN submission rejections

[Toby Hocking]

Hi Naras
I had a similar issue recently with
https://cloud.r-project.org/web/packages/nc/ --- it Suggests: re2r which is
a package that is no longer on CRAN, but available on github. To solve the
issue I just copied the re2r into a drat repo, which is a CRAN-like
repository hosted on github. More info on drat here
http://eddelbuettel.github.io/drat/DratForPackageAuthors.html So if those
solver packages you have in Suggests are open-source, you can just copy
them to your drat repo, and list that drat repo in Additional_repositories.
If they aren't open-source then you should provide a description of how to
obtain those packages in Description. Something like "gurobi package is not
available in any public open-source repositories but can be downloaded for
academic use free of charge from $GUROBI_URL"
BTW thanks for your efforts in getting CVXR on CRAN, that is really
important work!
Toby


On Wed, Sep 9, 2020 at 10:40 AM Balasubramanian Narasimhan <
na...@stanford.edu> wrote:

> We've been struggling to get past CRAN's rejections for a new upload of
> CVXR.  The new version makes essentially one change to the existing
> version on CRAN: the addition of a DOI to an article to appear in JSS.
> We realize that CRAN may tighten policies in the meantime forcing some
> changes to be made, which we are happy to do. But we are not sure what.
>
> The automated check
> <
> https://win-builder.r-project.org/incoming_pretest/CVXR_1.0-6_20200908_223033/>
>
> came back with 2 notes on Debian and Windows, both addressed in replies
> and submission comments. (Solaris failures are expected, also noted.)
>
> The communications with CRAN indicates that the problem might be that
> our package (the current version too) _suggests_ solvers not available
> on CRAN. These are either on github or on vendor websites (free to
> academics after login).  One reply from CRAN suggested that we either
> use the "Additional_repositories" field or provide some text in
> Description. The former is not applicable---these are not CRAN-like
> repositories---so we added text in the description with URL links.
>
> What could we be missing?
>
> Thanks.
>
> -Naras
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] new version jumps in minor?

[Toby Hocking]

Dear CRAN
I see a new NOTE, and I wonder if you would consider undoing this new
addition to checks? This would cause all of my packages to fail auto
checks, which would cause a lot of extra false positives, and lots of
extra work for both me and the CRAN team who works on approving
submissions which do not pass auto checks.
Thanks for your consideration

* checking CRAN incoming feasibility ... [11s] NOTE
Maintainer: 'Toby Hocking '

Version jumps in minor (submitted: 2024.11.2, existing: 2024.1.24)

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] new version jumps in minor?

[Toby Hocking]

I thought that the auto-check robot only accepts submissions which
have Status: OK? (no NOTEs at all)
Is it documented somewhere which NOTEs are allowed by the auto-check service?

On Tue, Nov 5, 2024 at 4:10 AM Uwe Ligges
 wrote:
>
> CRAN does not object to these versioning, the notes are not the reason
> for rejection. Who told they are?
>
> Best,
> Uwe Ligges
>
>
>
>
> On 05.11.2024 01:02, Josiah Parry wrote:
> > Rolf,
> >
> > The versioning method they’re using is referred to as CalVer
> > https://calver.org/ (not as catchy as SemVer) and it is actually quite
> > useful! With one look at the version you can get a good sense of it’s
> > general release date.
> >
> > Posit, for example, moved their professional products to use this
> > versioning method a number of years ago.
> >
> > I wouldn’t poopoo it so quickly!
> >
> > On Mon, Nov 4, 2024 at 15:32 Rolf Turner  wrote:
> >
> >>
> >> On Mon, 4 Nov 2024 16:33:40 -0500
> >> Toby Hocking  wrote:
> >>
> >> 
> >>
> >>> Version jumps in minor (submitted: 2024.11.2, existing: 2024.1.24)
> >>
> >> It looks to me that you are setting your version numbers in an
> >> unorthodox manner, which could/will confuse the living Drambuie out of
> >> people.
> >>
> >> I conjecture that you are setting your version number to represent the
> >> relevant date.  E.g. 2024.11.2  means 2 November, 2024 and 2024.1.24
> >> means 24 January 2024.
> >>
> >> In my understanding, the usual convention is for the version number to
> >> be of the form l.m.n (or l.m-n) --- major.minor.patch (or
> >> major.minor-patch).  The date should be specified in the *Date* field of
> >> the DESCRIPTION file.
> >>
> >> It probably does not matter a hell of a lot.  "Writing R Extensions"
> >> just says that the version number should be "a sequence of at least two
> >> (and usually three) non-negative integers separated by single ‘.’ or
> >> ‘-’ characters".
> >>
> >> However you might save yourself some "NOTEs" by adhering to the
> >> "l.m.n" convention and incrementing the components sequentially.
> >>
> >> cheers,
> >>
> >> Rolf Turner
> >>
> >> --
> >> Honorary Research Fellow
> >> Department of Statistics
> >> University of Auckland
> >> Stats. Dep't. (secretaries) phone:
> >>   +64-9-373-7599 ext. 89622
> >> Home phone: +64-9-480-4619
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] new version jumps in minor?

[Toby Hocking]

great thanks for the explanation Uwe

On Wed, Nov 6, 2024 at 4:01 AM Uwe Ligges
 wrote:
>
>
>
> On 05.11.2024 20:54, Iris Simmons wrote:
> > The auto checker will publish an R package that has Status: OK and no
> > Note_to_CRAN_maintainers.
> >
> > The auto checker will reject an R package that has WARNINGs and/or ERRORS.
> >
> > The auto checker will flag an R package for manual inspection otherwise. A
> > CRAN team member will see your NOTE and know it's nothing to worry about
> > and publish it anyway. I've had similar before, and I've waited at most 5
> > hours for someone to check and approve it.
>
> This is much more difficult.
>
> Most notes are actually also auo rejected, but not all, and that is a
> moving target, as we try to automate as much as possible.
>
> Jumps in version numbers or results of spell check have a non neglible
> probability of false positives, hence get manually inspected once raised
> by the auto check system.
>
> In this case the jump 1 --> 11 was flagged, because many people actually
> mean 1.1 instead, but it got manually confirmed and published.
>
> Best,
> Uwe Ligges
>
>
>
>
>
> > On Tue, Nov 5, 2024, 14:29 Toby Hocking  wrote:
> >
> >> I thought that the auto-check robot only accepts submissions which
> >> have Status: OK? (no NOTEs at all)
> >> Is it documented somewhere which NOTEs are allowed by the auto-check
> >> service?
> >>
> >> On Tue, Nov 5, 2024 at 4:10 AM Uwe Ligges
> >>  wrote:
> >>>
> >>> CRAN does not object to these versioning, the notes are not the reason
> >>> for rejection. Who told they are?
> >>>
> >>> Best,
> >>> Uwe Ligges
> >>>
> >>>
> >>>
> >>>
> >>> On 05.11.2024 01:02, Josiah Parry wrote:
> >>>> Rolf,
> >>>>
> >>>> The versioning method they’re using is referred to as CalVer
> >>>> https://calver.org/ (not as catchy as SemVer) and it is actually quite
> >>>> useful! With one look at the version you can get a good sense of it’s
> >>>> general release date.
> >>>>
> >>>> Posit, for example, moved their professional products to use this
> >>>> versioning method a number of years ago.
> >>>>
> >>>> I wouldn’t poopoo it so quickly!
> >>>>
> >>>> On Mon, Nov 4, 2024 at 15:32 Rolf Turner 
> >> wrote:
> >>>>
> >>>>>
> >>>>> On Mon, 4 Nov 2024 16:33:40 -0500
> >>>>> Toby Hocking  wrote:
> >>>>>
> >>>>> 
> >>>>>
> >>>>>> Version jumps in minor (submitted: 2024.11.2, existing: 2024.1.24)
> >>>>>
> >>>>> It looks to me that you are setting your version numbers in an
> >>>>> unorthodox manner, which could/will confuse the living Drambuie out of
> >>>>> people.
> >>>>>
> >>>>> I conjecture that you are setting your version number to represent the
> >>>>> relevant date.  E.g. 2024.11.2  means 2 November, 2024 and 2024.1.24
> >>>>> means 24 January 2024.
> >>>>>
> >>>>> In my understanding, the usual convention is for the version number to
> >>>>> be of the form l.m.n (or l.m-n) --- major.minor.patch (or
> >>>>> major.minor-patch).  The date should be specified in the *Date* field
> >> of
> >>>>> the DESCRIPTION file.
> >>>>>
> >>>>> It probably does not matter a hell of a lot.  "Writing R Extensions"
> >>>>> just says that the version number should be "a sequence of at least
> >> two
> >>>>> (and usually three) non-negative integers separated by single ‘.’ or
> >>>>> ‘-’ characters".
> >>>>>
> >>>>> However you might save yourself some "NOTEs" by adhering to the
> >>>>> "l.m.n" convention and incrementing the components sequentially.
> >>>>>
> >>>>> cheers,
> >>>>>
> >>>>> Rolf Turner
> >>>>>
> >>>>> --
> >>>>> Honorary Research Fellow
> >>>>> Department of Statistics
> >>>>> University of Auckland
> >>>>> Stats. Dep't. (secretaries) phone:
> >>>>>+64-9-373-7599 ext. 89622
> >>>>> Home phone: +64-9-480-4619
> >>>>>
> >>>>> __
> >>>>> R-package-devel@r-project.org mailing list
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>>>
> >>>>
> >>>>[[alternative HTML version deleted]]
> >>>>
> >>>> __
> >>>> R-package-devel@r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel