| Affiliation | https://pattern.institute |
| github | https://www.github.com/ramiromagno |
| github | https://www.github.com/patterninstitute |
| Affiliation | https://pattern.institute |
| github | https://www.github.com/ramiromagno |
| github | https://www.github.com/patterninstitute |
@yjunechoe @gaborcsardi (continue) I was under the impression I could not go beyond the three components with CRAN but that might have been some influence from reading tidyverse guidelines in the past: https://r-pkgs.org/lifecycle.html#sec-lifecycle-version-number-tidyverse.
Do you guys actually know of a CRAN package using calendar versioning?
@yjunechoe Thanks for the pointer! I don't have control over the release dates (upstream), although in my case that is actually quite predictable, like every quarter, so it is not too often, and should be fine with CRAN.
Now that I was looking into it more closely, it seems that you're not even forced to limit yourself to x.y.z on CRAN, and calendar versions seem to be possible too: https://forum.posit.co/t/cran-package-version-guidelines/156330 (thanks @gaborcsardi ) ;)
From what I understand, CRAN packages are ideally supposed to follow semantic versioning (X.Y.Z) similar to R itself. However, other version schemes exist. For example, RStudio uses calendar-based versioning (YYYY.MM.patch). A long time ago, I tried to submit a package to CRAN and there was a problem with the version formatting (2022.01 did not work, but 22.1 was okay). Now I cannot seem to find these rules. Are they explicitly stated somewhere? And more specifically, which variants of calendar ...
#rstats hivemind: would it be too funky to define a package version major.minor.patch.dev as YYYY.MM.DD.VERSION, i.e. map major to year, minor to month, patch to day, and leave the dev component for the actual version..? I'm thinking of a data package whose upstream data releases are versioned based on the date... anyone ever tried such heretic approach? Would CRAN maintainers be okay with this?! ;)
asking for a friend.