Skip to content
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
Closed

Starting package version should be 0.0.0.9000 #632

hadley opened this issue Nov 3, 2014 · 12 comments

Comments

@hadley
Copy link
Member

@hadley hadley commented Nov 3, 2014

No description provided.

@gaborcsardi
Copy link
Contributor

@gaborcsardi 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
Copy link
Member Author

@hadley 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
Copy link
Contributor

@gaborcsardi 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
Copy link
Member

@krlmlr 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
Copy link
Contributor

@gaborcsardi 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
Copy link
Member Author

@hadley 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
Copy link
Contributor

@gaborcsardi 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
Copy link
Contributor

@gaborcsardi 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
Copy link
Member Author

@hadley 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
Copy link
Contributor

@gaborcsardi 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
Copy link

@sanmai-NL 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
Copy link

@lock 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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants