[Rd] Allow semantic versioning for packages

[Simon Urbanek]

On Oct 5, 2013, at 9:19 PM, Gábor Csárdi <csardi.gabor at gmail.com> wrote:

> On Sat, Oct 5, 2013 at 2:23 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
> Gabor,
> 
> On Oct 5, 2013, at 4:58 PM, Gábor Csárdi <csardi.gabor at gmail.com> wrote:
> 
> > Simon,
> >
> > I think there is a misunderstanding here. I am not suggesting anarchy, completely the opposite.
> >
> > Semantic versioning as defined on http://semver.org was designed exactly for being able to order the versions, and being able to express release candidates, alpha and beta builds, etc. An example ordering from the homepage:
> >
> > 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
> >
> > Currently there is no way to give a version number to my builds that are in between releases. Having multiple branches of development is even more problematic.
> >
> > My problem is not that I am forced to use something meaningful. My problem is that the system I am forced to use is not expressive enough.
> >
> > Hope it is clearer now.
> 
> Yes, thanks. The way I understand it, you are proposing extensions to the existing scheme that allow arbitrary additional content in the version numbers that is to be ignored.
> 
> Nothing is ignored in the version string IMHO.
>  

e.g. quoting the spec: "Build metadata SHOULD be ignored when determining version 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. 


> so I don't think it can be adapted as-is, but one could cook up something similar with slightly different rules which define which part is ignored. It may break existing tools, so it would have to be considered carefully.
> 
> Indeed, it may break existing tools depending on how they are programmed. The current (3.0.2) version of compareVersion() fails:
> 
> 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).

Cheers,
Simon



> So, yes, this is something that you don't want to introduce immediately. But maybe in a new major version it could be done. 
> 
> I understand if you say it is not worth the trouble, this is up to you to decide.
> 
> Actually I don't know how you create version strings for R itself currently, I mean, for patched versions, release candidates, devel builds, etc. I guess for R the number.number.number rule does not apply.
> 
> Best,
> Gabor
> 
> 
>  
>  
> 
> Cheers,
> Simon
> 
> 
> > Gabor
> >
> > On Sat, Oct 5, 2013 at 7:42 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
> > Gabor,
> >
> > what you propose is not really feasible, because R relies on the fact that it can meaningfully order the the versions as to determine the update order. If you use arbitrary strings then ordering becomes random - that's why git commit hashes are so useless for this purpose. The fact that you are forced to use something meaningful is for a good reason here.
> >
> > Cheers,
> > Simon
> >
> >
> > On Oct 4, 2013, at 8:53 PM, Gábor Csárdi <csardi.gabor at gmail.com> wrote:
> >
> > > Dear R developers,
> > >
> > > (http://bugs.r-project.org/ seems to be down, so I am writing a feature
> > > request here.)
> > >
> > > It would be great to allow semantic version numbers for packages. See
> > > http://semver.org/ for details.
> > >
> > > The problem I am having is that I am setting up a nightly build server, and
> > > there is no easy way to create a version number for builds that are in
> > > between releases.
> > >
> > > Ideally I would use something like
> > >
> > > TAG+DIST.HASH
> > >
> > > TAG is the last tag of the git branch, usually something like
> > > MAJOR.MINOR.PATCH, DIST is the number of commits since the last release and
> > > HASH is the first seven letters of the git hash for the commit. E.g.
> > >
> > > 0.7.0-pre+518.badcafe
> > >
> > > Right now instead of this I am forced to use something like
> > >
> > > 0.6.999.518
> > >
> > > which is a lot less expressive and there is no (easy) way to include the
> > > branch information.
> > >
> > > Thanks, Best Regards,
> > > Gabor
> > >
> > >       [[alternative HTML version deleted]]
> > >
> > > ______________________________________________
> > > R-devel at r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> >
> 
>