[R-pkg-devel] Versioning conventions
henrik@bengt@@on @ending from gm@il@com
Tue Jul 10 16:14:49 CEST 2018
On Tue, Jul 10, 2018 at 7:00 AM David Hugh-Jones
<davidhughjones using gmail.com> wrote:
> Hi all,
> Just updated my rcheology package with data on functions for R 3.5.1 (no
> change from R 3.5.0 afaik). See https://github.com/hughjonesd/rcheology.
> I'm wondering how to version this package. It's not on CRAN yet so it would
> be good to get things right.
> * Just copy the R versions, so the new version would be 3.5.1
> Advantages: easy to understand. Disadvantages: semantic versioning would
> follow R, not the package itself (which does contain a single function with
> a public API); what if I make changes between R releases.
If you want to convey (the upper-limit) support for the R version, I
like this one. You can start with rcheology 3.5.1. If you do need to
do minor updates in the meanwhile, you can tag on another level, e.g.
> * ownversion.major.minor-Rversion.major.minor e.g. 0.1.0-3.5.1
FYI, this may be rendered differently at different places, e.g.
> Advantages: shows the R version clearly, contains own semantic versioning
> information. Disadvantages: long.
> * ownversion.major.minor-Rversionmajorminor e.g. 0.1.0-351
> Advantage: as above but shorter. Disadvantages: if we hit e.g. 3.10.0, then
> go back to 4.0.0, then we'd end up going backward in the last component.
Similarly, now you cover R 2.0.0 - R 3.5.0, that would be rcheology
2.0.0-3.5.0, but if/when you to dig further back to you'll end up
decreasing your version number with this version model, e.g. rcheology
PS. For people who don't this package, see its Shiny front-end
> Any ideas?
> [[alternative HTML version deleted]]
> R-package-devel using r-project.org mailing list
More information about the R-package-devel