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.urba...@r-project.org>
> wrote:
> On Oct 5, 2013, at 9:19 PM, Gábor Csárdi <csardi.ga...@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
>
> [...]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
