On Sat, Oct 5, 2013 at 2:23 PM, Simon Urbanek
<simon.urbanek@r-project.org>wrote:

> Gabor,
>
> On Oct 5, 2013, at 4:58 PM, Gábor Csárdi <csardi.gabor@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.


> 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.


> 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

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@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@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@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> >
>
>

	[[alternative HTML version deleted]]

