Starting package version should be 0.0.0.9000

[hadley]

No description provided.

[gaborcsardi]

I guess this is a matter of choice, largely. However, note that semver.org has this:

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

[hadley]

Yes, but this is the version prior to the first release so it needs to be less than 0.1.0. 0.0.1.9000 could be an option, but I don't think it makes much difference.

[gaborcsardi]

Sure, that makes sense, I didn't immediately realize that you want a version number that refers to the state before a release. It is a pity that you cannot have 0.1.0-dev or something like that. :(

[krlmlr]

I have the following in my .Rprofile, among other things:

options(
devtools.desc = list(Encoding = "UTF-8", Version = "0.0-0")
)

[gaborcsardi]

@krlmlr That is fine with R, but I would encourage some numbering that conforms to http://semver.org, because it is becoming a standard in the JS, Ruby, etc. world.

[hadley]

@gaborcsardi what would you prefer? semver only governs released versions. I think using the four component for dev versions is reasonable (and it's used by a lot of personal and rstudio packages so we're unlikely to change)

[gaborcsardi]

We can choose something that is valid for R, smaller than 0.1.0, and also valid semver, and smaller than 0.1.0 for semver as well. These are not valid semver:

semver::valid("0.0-0")
#> NULL
semver::valid("0.0.0.9000")
#> NULL

These are valid:

semver::valid("0.0.0")
#> [1] "0.0.0"
semver::valid("0.1.0-99")
#> [1] "0.1.0-99"
semver::valid("0.0.1-99")
#> [1] "0.0.1-99"
semver::valid("0.0.0-99")
#> [1] "0.0.0-99"
semver::valid("0.0.0-9000")
#> [1] "0.0.0-9000"
semver::valid("0.0.0-0")
#> [1] "0.0.0-0"
semver::valid("0.0.0-1")
#> [1] "0.0.0-1"

I think 0.0.1-99 is somewhat strange, because we set the patch version to 1, 0.1.0-99 is bigger than 0.1.0, so that is not good, either.

I think 0.0.0-9000, or even 0.0.0-1 or 0.0.0-0 are good.

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. 0.9.0-999? So I guess 0.0.0-9000 is fine, and it is almost what you wanted in the first place.

[gaborcsardi]

Although the ordering of R and semver will never match, of course. E.g. 0.0.0-99 is smaller than 0.0.0 in semver:

semver::lt("0.0.0-99", "0.0.0")
#> [1] TRUE

but in R the opposite is true:

package_version("0.0.0-99") < package_version("0.0.0")
#> [1] FALSE

[hadley]

I don't see being valid semi a particularly strong restraint. Versioning in R is always going to be fundamentally different from other programming languages.

[gaborcsardi]

I guess you are right. So, whatever is fine then. :)

[sanmai-NL]

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:

Version: 0.1

Although there is indeed a deviation between SemVer and R's treatment of

package_version("0.1.0") < package_version("0.1.0-9000")
#> [1] TRUE

This can be easily circumvented using a default initial version of

package_version("0.1.0-2") < package_version("0.1.0-1")
#> [1] FALSE

@hadley, you wrote at the time that SemVer is only for released versions. However, SemVer 2.0.0 states:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

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 DESCRIPTION and devtools take the SemVer compatible default of 0.1.0 instead of 0.1.

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.

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/