Proposal: version() function to return semver version

[Paul Jolly]

Hi all,

I'd like to propose a version() function (or variable I guess?) that
returns a string that is the semver version of Vim, i.e. v8.1.1518

Parsing this in a locale-aware manner from the output of :version is
brittle (particularly if we consider MacVim messes with that output
slightly)

A specific function/variable feels much more robust.

Anyone have any thoughts? Or have I simply missed something very
obvious along the way?

Many thanks,


Paul

[James McCoy]

On Thu, Jun 13, 2019, 10:43 Paul Jolly <pa...@myitcv.io> wrote:

Hi all,

I'd like to propose a version() function (or variable I guess?) that
returns a string that is the semver version of Vim, i.e. v8.1.1518

Sounds like you're looking for the v:version variable.

Cheers,

James

[Paul Jolly]

>> I'd like to propose a version() function (or variable I guess?) that
>> returns a string that is the semver version of Vim, i.e. v8.1.1518
>
> Sounds like you're looking for the v:version variable.

Thanks. I'd see that, but it does not include the patch information,
i.e. 801, unless I'm missing something obvious?

Ideally, I think we should have a direct means to get at the semver
version of Vim.

[Andy Massimino]

It is better to check for a patch directly: has('patch-8.1.1518').  It's plausible someone would build with a subset of patches (and neovim does this). 

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn4X-Ag%3DkMrvBEeHRMu4rtuhm2REwWnvfeZugZEnJtbSDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Bram Moolenaar]

What do you want to use the patchlevel for? If it's about checking for
a certain feature, use this:
if has("patch-7.4.248")

":help has-patch" for details.


--
hundred-and-one symptoms of being an internet addict:
166. You have been on your computer soo long that you didn't realize
you had grandchildren.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Paul Jolly]

> What do you want to use the patchlevel for? If it's about checking for
> a certain feature, use this:
> if has("patch-7.4.248")
>
> ":help has-patch" for details.

Thanks, Bram and Andy.

In much the same vein as the config functions discussion, I want to
push data to govim rather than have it pull it (because that involves
a round trip). A call to has("xxx") involves a roundtrip from govim ->
Vim. If this is on a hot path, it gets expensive.

And it's totally unnecessary because the version of Vim will not
change from the start.

> It's plausible someone would build with a subset of patches (and neovim does this).

That's not something I'm solving for here. I'm only looking to support
tagged versions of Vim/Gvim. Neovim will similarly be tested against
tagged versions, and the checks there will be against the Neovim
version (because that's what the user installs/knows).

For example, I have a minimum required version to use govim of
Vim/Gvim v8.1.1158. In order to take advantage of delta-based updates
(that use listener_add) you need at least v8.1.1512.

[Bram Moolenaar]

Hmm, it's possible if you ignore security fixes, these sometimes skip a
longer range of patches.

We could add v:longversion or v:versionlong, with:

major version (one digit)
minor version (two digits)
patchlevel (four digits)

Current version would be 8011523. Then you can easily compare with the
version you need, no string parsing or anything.

--
"Hit any key to continue" does _not_ mean you can hit the on/off button!

[Paul Jolly]

> Hmm, it's possible if you ignore security fixes, these sometimes skip a
> longer range of patches.
>
> We could add v:longversion or v:versionlong, with:
>
> major version (one digit)
> minor version (two digits)
> patchlevel (four digits)
>
> Current version would be 8011523. Then you can easily compare with the
> version you need, no string parsing or anything.

I'd prefer the semver string to be honest, v8.1.1512. Neovim's
releases are also semver tagged.

It's also the string the user will know:

https://github.com/vim/vim/releases
https://github.com/neovim/neovim/tags

It's also the string I will output to users saying "hey, you need to
be on version X for this feature"

Because Go modules is entirely based around semver versions, dealing
with them is trivial:

https://godoc.org/github.com/rogpeppe/go-internal/module

(there is also a more standard package proposed). So, on that front I'm sorted.

[Bram Moolenaar]

Paul Jolly wrote:

> > Hmm, it's possible if you ignore security fixes, these sometimes skip a
> > longer range of patches.
> >
> > We could add v:longversion or v:versionlong, with:
> >
> > major version (one digit)
> > minor version (two digits)
> > patchlevel (four digits)
> >
> > Current version would be 8011523. Then you can easily compare with the
> > version you need, no string parsing or anything.
>
> I'd prefer the semver string to be honest, v8.1.1512. Neovim's
> releases are also semver tagged.

I have never heard of the term semver. I thought it was a typo.

> It's also the string the user will know:
>
> https://github.com/vim/vim/releases
> https://github.com/neovim/neovim/tags
>
> It's also the string I will output to users saying "hey, you need to
> be on version X for this feature"

Turning the number into a message is trivial, while using the string in
an "if" statement is not.

> Because Go modules is entirely based around semver versions, dealing
> with them is trivial:
>
> https://godoc.org/github.com/rogpeppe/go-internal/module
>
> (there is also a more standard package proposed). So, on that front
> I'm sorted.

Hardly anybody writes go for a Vim plugin, thus this is irrelevant.
I'm much more interested in something that works in a Vim script.

--
"Hit any key to continue" is a lie.

[Paul Jolly]

Turning the number into a message is trivial, while using the string in
an "if" statement is not.

Good point. I was indeed thinking too much from a Go perspective.

How about returning a triple:

[8, 1, 1512]?

[Bram Moolenaar]

Paul Jolly wrote:

> > Turning the number into a message is trivial, while using the string in
> > an "if" statement is not.
>
> Good point. I was indeed thinking too much from a Go perspective.

People who use Go are crazy, never do what they do!
(just kidding, of course).

> How about returning a triple:
>
> [8, 1, 1512]?

Why? What would you use the "1" for? You can get the minor version
with:
v:versionlong % 10000

And the major version with:

v:versionlong / 1000000

But the very common use would be:

if v:versionlong > 8011522
" Use the user friendly popup_notification()
else
" fall back to annoying :echomsg
endif

--
hundred-and-one symptoms of being an internet addict:

169. You hire a housekeeper for your home page.

[Paul Jolly]

> People who use Go are crazy, never do what they do!
> (just kidding, of course).

I'm looking forward to the first commit to the Vim repo that is a .go file ;-)

> > How about returning a triple:
> >
> > [8, 1, 1512]?
>
> Why?

No particular reason, other than the fact I felt having a triple was
less brittle than encoding in a single number - you'll know better
than me whether we're likely to breach the various limits on
major/minor/patch in that scheme.

But also that (see below) I consume semver strings and so will likely
continue to use them, rather than encoding.

> But the very common use would be:
>
> if v:versionlong > 8011522
> " Use the user friendly popup_notification()
> else
> " fall back to annoying :echomsg
> endif

Yes, this is the kind of pattern I use.

The v:versionlong value is something that I will "push" to govim at
startup, but this is just a minor detail to avoid roundtrips as I
mentioned.

Given that govim itself predominantly consumes semver
(https://semver.org for reference) strings, either I convert those
semver strings (which are exactly the tags in the Vim repo) to numbers
following the same encoding above, or keep them as strings and use
existing libraries to work with them.

The triple suggestion was really a nod to the very fair point that not
everyone wants semver (wants to quickly work with maj/min/patch) but
that for those who do it's easily built.

Thanks

[Christian Brabandt]

On Do, 13 Jun 2019, Bram Moolenaar wrote:

> We could add v:longversion or v:versionlong, with:
>
> major version (one digit)
> minor version (two digits)
> patchlevel (four digits)

We already have v:version

Why not just add a simple v:patchlevel which contains the last patch
included?

I am not sure if we actually need this, considering that there exist Vim
version, that leave out just a single patch in between, so even when
checking for the existence of 8.1.1152, that does not mean that the Vim
used does support all the features that have been added in the previous
1151 patches.

I think a better way is to check for the existence of the feature to be
used using has()/exists(), etc.

Best,
Christian
--
So geht es oft mit einer Unterhaltung: Nach einer Weile vergeblicher
Auseinandersetzung merkt man, daß man gar nicht von derselben Sache
gesprochen hat.
-- André Gide

[Bram Moolenaar]

Christian wrote:

> On Do, 13 Jun 2019, Bram Moolenaar wrote:
>
> > We could add v:longversion or v:versionlong, with:
> >
> > major version (one digit)
> > minor version (two digits)
> > patchlevel (four digits)
>
> We already have v:version
>
> Why not just add a simple v:patchlevel which contains the last patch
> included?

Because then you need a more complicated condition:

if v:version > 801 || (v:version == 801 && v:patchlevel > 1234)

This is a lot simpler:

if v:versionlong > 8011234

> I am not sure if we actually need this, considering that there exist Vim
> version, that leave out just a single patch in between, so even when
> checking for the existence of 8.1.1152, that does not mean that the Vim
> used does support all the features that have been added in the previous
> 1151 patches.
>
> I think a better way is to check for the existence of the feature to be
> used using has()/exists(), etc.

Yes, that is the safe way. But Paul made a point for what he wanted,
and it's a very small change.

--
Living in Hollywood is like living in a bowl of granola. What ain't
fruits and nuts is flakes.

[Bram Moolenaar]

> > People who use Go are crazy, never do what they do!
> > (just kidding, of course).
>
> I'm looking forward to the first commit to the Vim repo that is a .go
> file ;-)

No, that would be Zimbu (it's like NeoGo). It has classes and
exceptions, like any decent programming language.
Oh, no, now I started a language war!

In a compiled language it might be OK to deal with strings, split them
and the like, but for Vim script we try to keep it efficient. I'll add
v:versionlong then.


--
Very funny, Scotty. Now beam down my clothes.

[Paul Jolly]

> Yes, that is the safe way. But Paul made a point for what he wanted,
> and it's a very small change.

Thanks, Bram. Just saw the commit too.

I very much appreciate the discussion and understand the reasons
behind the has()/exists() suggestions.

But as explained, my whole testing approach is based on minimum
versions of Vim (for specific features). If the minimum version (for a
feature) needs to increase for whatever reason, then that's exactly
what I require, a higher minimum version.