[R-pkg-devel] Versioning conventions
d@vidhughjone@ @ending from gm@il@com
Tue Jul 10 17:53:47 CEST 2018
Sounds like people favour 18.104.22.168 as the style. Seems reasonable.
On Tue, 10 Jul 2018 at 16:00, Hugh Parsonage <hugh.parsonage using gmail.com>
> 22.214.171.124 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>
> > 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
> > 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
> > 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,
> > 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
[[alternative HTML version deleted]]
More information about the R-package-devel