New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Starting package version should be 0.0.0.9000 #632

Closed
hadley opened this Issue Nov 3, 2014 · 12 comments

Comments

Projects
None yet
4 participants
@hadley
Member

hadley commented Nov 3, 2014

No description provided.

@gaborcsardi

This comment has been minimized.

Member

gaborcsardi commented Nov 3, 2014

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

This comment has been minimized.

Member

hadley commented Nov 4, 2014

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

This comment has been minimized.

Member

gaborcsardi commented Nov 4, 2014

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

This comment has been minimized.

Member

krlmlr commented Nov 4, 2014

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

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

@gaborcsardi

This comment has been minimized.

Member

gaborcsardi commented Nov 4, 2014

@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

This comment has been minimized.

Member

hadley commented Nov 4, 2014

@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

This comment has been minimized.

Member

gaborcsardi commented Nov 4, 2014

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

This comment has been minimized.

Member

gaborcsardi commented Nov 4, 2014

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

This comment has been minimized.

Member

hadley commented Nov 4, 2014

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

This comment has been minimized.

Member

gaborcsardi commented Nov 4, 2014

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

@hadley hadley closed this in fbcdd80 Nov 5, 2014

@sanmai-NL

This comment has been minimized.

sanmai-NL commented Oct 3, 2015

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 comment has been minimized.

lock bot commented Sep 18, 2018

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/

@lock lock bot locked and limited conversation to collaborators Sep 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.