Build with Release mode and v0.5.0 version

[stsewd]

Hi, I noticed the builds are using RelWithDebInfo instead of Release. Not sure if this was on purpose, also, I'd sent a PR, but I'm not really familiar with packaging.

https://github.com/neovim/neovim/wiki/Building-Neovim#building

[agriffis]

Hi! The spec we use is modeled after the Fedora spec, with just the versioning changes needed for building from git master.

The Fedora spec uses RelWithDebInfo https://src.fedoraproject.org/rpms/neovim/blob/master/f/neovim.spec#_97

The RPM build process splits out the debuginfo into a separate package, and strips the main binary, so the effect is largely the same as building with Release except that it's possible to reconstruct a stack trace.

You can see the debuginfo package in the listing of dnf search neovim

Hope that helps!

[stsewd]

Thanks for the clarification! I have another question, is it possible to change the version number?

Available Packages
Name         : neovim
Version      : 0.4.4.0.git.15717.55add1c1c
Release      : 1.fc33
Architecture : src
Size         : 9.5 M
Source       : None
Repository   : copr:copr.fedorainfracloud.org:agriffis:neovim-nightly
Summary      : Vim-fork focused on extensibility and agility
URL          : https://neovim.io
License      : ASL 2.0

From dnf it's listed to 0.4.4, but the commit is from the nightly build.

https://github.com/agriffis/neovim/blob/54d1550d859f77c8bb0f27659ffe0bd2b7a3a9bc/neovim.spec.rpkg#L21

So, I guess that could be changed to be hardcoded as nighttly instead, or use the nightly tag https://github.com/neovim/neovim/tree/nightly

Other part were the version could be improved is on:

$ nvim --version
NVIM v0.5.0-dev

When using the appimage for example, it gives you the commit as well, that's useful when reporting bugs, I'm not sure where to change that one.

[agriffis]

That might be possible. The current versioning of the rpm has these components:

0.4.4.0.git.15717.55add1c1c
^^^^^ ^^^^^ ^^^^^ ^^^^^^^^^
  |     |     |   commit hash from git master
  |     |   build sequence number
  |   constant string
last upstream tag

This satisfies some rules:

1. The version is semantically BETWEEN the current stable release, and the next stable release, so that dnf upgrade works properly, especially toggling between COPR and Fedora packaged.
2. Since it's based on tags, it's fully automated in my build process and doesn't require manual intervention to bump anything.

To continue adhering to these rules, we need to:

1. Get the 0.5.0 version string from the CMakefile.
2. Use the tilde separator to indicate a pre-release.

so the final version string won't match the appimage exactly, especially punctuation and the build sequence number, but it will still have the 0.5.0 and the git hash, something like 0.5.0~dev.15717.55add1c1c

It's not clear to me yet what the best way is to modify the build process to update nvim --version. Do you know?

Also, could you tell me if this discrepancy is causing you problems in practice, or if it's just a curiosity? The automated build process works reliably now and makes sense, even if the sense is different from how it's done in the appimage. I'd rather not fiddle with it too much unnecessarily, especially because it's a common build process for a number of COPR repos, all using the same version-building logic.

[agriffis]

Here's another approach to pre-release versioning for rpms:

https://serverfault.com/questions/454462/incremental-rpm-package-version-numbers-for-x-y-z-x-y-z-beta-or-alpha-rc/867567#867567

That would result in a version string like this:

0.5.0-0.dev.15717.55add1c1c

The dash is special in rpm versioning—it separates the upstream version from the package build—effectively this provides a way to version the rpm so the package maintainer can bump it when making changes to the spec, such as security fixes or updating dependencies.

Normally the release starts at 1 so by using 0 it's an easy way to have a sortable pre-release that will automatically be replaced by the released version when it's available.

I'm not seeing any examples of the tilde approach in existing Fedora packages, so probably I'd opt for this approach instead to stay consistent. This is supposed to be a bleeding edge version of Neovim, not a bleeding edge version of packaging ;-)

[stsewd]

Thanks for detailed information!

Also, could you tell me if this discrepancy is causing you problems in practice, or if it's just a curiosity?

It was just weird, when installing/updating seeing 4.0 instead of nightly or 5.0 (first time I thought I didn't setup the package correctly)

It's not clear to me yet what the best way is to modify the build process to update nvim --version. Do you know?

Looks like that number comes from https://github.com/neovim/neovim/blob/faa47eafffe35ddfdee44d341d7dc06e97377b28/src/nvim/version.c#L33, but in neovim's builds it gets re-defined via this script https://github.com/neovim/neovim/blob/ee5ece084cf76fc90f0bd3aa4e0ddeaaca0bc51a/scripts/update_version_stamp.lua#L41

[agriffis]

Fixed by 91c9665b9a95ab45e5dbd7e1e67b74cb56f1c1bf

[stsewd]

Fixed by 91c9665

thanks!

[dietrichm]

I noticed this version format change causes an issue for coc.nvim, failing to load: https://github.com/neoclide/coc.nvim/issues/2881

The regexp used to read the Neovim version does no longer work, probably because v was dropped and ~ is used instead of a hyphen. Waiting for the plugin author to check, but just a heads up if anyone comes across the same issue.

[agriffis]

Thanks, that's a mistake on my part. I didn't mean to drop the v.

[agriffis]

Fixed by f5d43cb2effd51c3fb793dff9976905778fb2160

✸ rpm -q neovim
neovim-0.5.0~dev.1083.g1aec5ba85-388.fc33.x86_64

✸ nvim --version
NVIM v0.5.0-dev+1083-g1aec5ba85

[dietrichm]

Hey

I was unaware of any conventions regarding the version number format.

Thanks for fixing this! And thanks for offering the COPR repo and putting all the work in this!

Dietrich