Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Starting package version should be 0.0.0.9000 #632
I guess this is a matter of choice, largely. However, note that semver.org has this:
We can choose something that is valid for R, smaller than
semver::valid("0.0-0") #> NULL semver::valid("0.0.0.9000") #> NULL
These are valid:
semver::valid("0.0.0") #>  "0.0.0" semver::valid("0.1.0-99") #>  "0.1.0-99" semver::valid("0.0.1-99") #>  "0.0.1-99" semver::valid("0.0.0-99") #>  "0.0.0-99" semver::valid("0.0.0-9000") #>  "0.0.0-9000" semver::valid("0.0.0-0") #>  "0.0.0-0" semver::valid("0.0.0-1") #>  "0.0.0-1"
I don't really understand why you would want the last, fourth number to be big, to be honest. Because it will be similar later, for larger version numbers, i.e.
I would like to bring this issue up again. I do not see a very strong case to deviate the R versioning scheme from Semantic Versioning 2.0.0, given that the R-exts documentation seems compatible with this widely adopted standard.
First of all, currently the initial version as prescribed in the development guide appears to be:
Although there is indeed a deviation between SemVer and R's treatment of
package_version("0.1.0") < package_version("0.1.0-9000") #>  TRUE
This can be easily circumvented using a default initial version of
package_version("0.1.0-2") < package_version("0.1.0-1") #>  FALSE
@hadley, you wrote at the time that SemVer is only for released versions. However, SemVer 2.0.0 states:
I don't believe that R versioning must necessarily be out of step with conventions for general purpose programming languages. For e.g. Python, some deviation happens for PEP 0440 compliance. But if there is a lack of such a standardized convention in R, then I would suggest that the example
The practical benefit: such an improvement allows you to refer your readership and user base to SemVer, if they want to come to understand the logic of software versioning, even if they are R package developers not familiar with software engineering practices. That would encourage good package development practices, e.g. understanding the difference between essential quality levels of software and how to communicate them.