From simon.urbanek at r-project.org  Tue Oct  8 17:14:54 2013
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Tue, 8 Oct 2013 11:14:54 -0400
Subject: [Rd] Allow semantic versioning for packages
In-Reply-To: <CABtg=KmfujFJq+w0B0CYA5A6cFkV1XWDH+nwpM5=d5UXH6Z6OA@mail.gmail.com>
References: <CABtg=K=AB=eJu3dtEvqOtA0o_R37OdwNAZw=X-TDePJwLKnQDg@mail.gmail.com>
	<7779BA7B-8282-44BA-9EB9-C16B33D88840@r-project.org>
	<CABtg=K=rXyCtGmfhBa5EesSAATJiSUezm7JgTJYGCHXCx3ZZOQ@mail.gmail.com>
	<3015BC91-3B84-4AAF-9490-9C6FE4A4EEF1@r-project.org>
	<CABtg=Kknq3SW-E=LPNBiSrat9NERTATrtedXe46qcCw5tOKRQg@mail.gmail.com>
	<6B0E7890-061E-4D35-A04C-66C1C553F0FF@r-project.org>
	<CABtg=KmfujFJq+w0B0CYA5A6cFkV1XWDH+nwpM5=d5UXH6Z6OA@mail.gmail.com>
Message-ID: <233A67CE-CE44-4506-90B2-151285B0F816@r-project.org>

On Oct 7, 2013, at 7:35 PM, G?bor Cs?rdi wrote:

> On Mon, Oct 7, 2013 at 6:32 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
> On Oct 5, 2013, at 9:19 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
> [...] 
> e.g. quoting the spec: "Build metadata SHOULD be ignored when determining version precedence."
> 
> Indeed, although 'SHOULD' means that it is only a recommendation. And the build metadata is the stuff after the plus sign, so the -alpha, -beta, etc. is still used to determine precedence.
> 
> > I fear that the scheme as described in semver.org is incompatible with the scheme used by R,
> >
> > I believe that they are fully compatible. In the sense that the current R package versioning is a subset of the one at semver.org. In other words, the current compareVersion only gives results that are valid according to semver.org.
> >
> 
> Nope, e.g. the most commonly used format 1.0-0 is not even allowed by semver.
> 
> Indeed again, I overlooked that the three numbers are required. This is something that should be relaxed for R packages, the patch level can be omitted.
> 

That's not what it means in R - the number after the dash *is* the patch level. The point is that the semantics of the dash are different in the two standards and so is the interpretation of the components. That's why I said earlier (in the part that you cut out) that probably the only viable option is to enhance the R handling to add some handling of non-integer components.


> You are right, maybe semver.org is something that is appropriate for R packages, as it is. But I guess, my feature request still makes sense. I just want to be able to use more flexible version strings, and I think semver.org is a good starting point, nevertheless.
> 
> Again, I understand if you say, that it would cause too much trouble for CRAN for not too much benefit. I cannot estimate the amount of extra work required. As for updating the compareVersion function, that is probably not too bad, there is an existing Python package for it called semver, so that could be the starting point.
> 

Updating compareVersion() is the least problem - tools that handle package files often use regexps which will fail once non-intergers are allowed.

Cheers,
Simon


> [...]
> > compareVersion("1.0.0", "1.0.0-alpha")
> > # [1] -1
> > # Warning message:
> > # In compareVersion("1.0.0", "1.0.0-alpha") : NAs introduced by coercion
> >
> 
> 
> It doesn't fail - just the order inverse to that defined by semver, because R treats all parts as integers, regardless of how many exist, and the existence of any additional components has higher precedence than the lack thereof (assuming full match on existing ones).
> 
> Well, there are surely some for which it fails, e.g.:
> 
> compareVersion("1.0-alpha", "1.0-beta")
> # Error in if (a[k] > b[k]) return(1) else if (a[k] < b[k]) return(-1L) : 
> #   missing value where TRUE/FALSE needed
> # In addition: Warning messages:
> # 1: In compareVersion("1.0-alpha", "1.0-beta") : NAs introduced by coercion
> # 2: In compareVersion("1.0-alpha", "1.0-beta") : NAs introduced by coercion
> 
> Thanks for taking the time to discuss this issue!
> 
> Best,
> Gabor
>  
> 
> Cheers,
> Simon
> 
> [...] 



[Rd] Allow semantic versioning for packages
Simon Urbanek