[R-pkg-devel] Versioning conventions

Hugh Parsonage hugh@p@r@on@ge @ending from gm@il@com
Tue Jul 10 16:59:19 CEST 2018


3.5.1.0 with the 4th number (0) for within-release changes.

Lovely package by the way -- I was looking for it earlier this year
but thought it had been lost!

The link in the GitHub description appears broken, however.

On 10 July 2018 at 23:59, 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.
>
> Possibilities:
>
> * 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.
> * ownversion.major.minor-Rversion.major.minor e.g. 0.1.0-3.5.1
> 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.
>
> Any ideas?
>
> Cheers,
> David
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list