I admitedly don't know how versioning works. But Neovim must be one of the most complete and realiable 0.12 program out there. I don't reallly use it anymore though. I understand Lua is a treat to...
I admitedly don't know how versioning works. But Neovim must be one of the most complete and realiable 0.12 program out there.
I don't reallly use it anymore though. I understand Lua is a treat to programmers, but I'm not one. It completely removed my joy when interacting with Neovim. I just use Emacs for that stuff now. I'm pretty sure they will never change its configuration language.
Based off the 3 version numbers 0.12.0 it seems they use semantic versioning, which divides the 3 version numbers into MAJOR.MINOR.PATCH. Major versions are supposed to be breaking changes, minor...
Based off the 3 version numbers 0.12.0 it seems they use semantic versioning, which divides the 3 version numbers into MAJOR.MINOR.PATCH. Major versions are supposed to be breaking changes, minor upgrades that are backwards compatible and patches for bugfixes only.
This versioning scheme makes the most sense for libraries, i.e. code that is meant to be used by other code, because you can tell at a glance if you as the user of such libraries need to change something. Minor and patch versions are drop in replacements, major require some changes on your end to get your code to work again.
This is really just the idea, and nothing says that you have to adhere to these rules. Sometimes software increments the major version if some new big feature is getting released.
It’s a meme, but there’s also a pretty large kernel of truth in most semver projects actually incrementing based on how proud the developers are of a given checkpoint. In my experience it also...
It’s a meme, but there’s also a pretty large kernel of truth in most semver projects actually incrementing based on how proud the developers are of a given checkpoint. In my experience it also maps to the fact that deep fundamental unix packages like this never hit a 1.0 release - the kind of mind that’ll work on a fork of a reimplementation of a terminal text editor from 1976 and do a damn good job of it is never satisfied with their own work!
There are also the cautionary tales of jumping too far quickly, for example Linus Torvalds went from 0.12 to 0.95 of Linux, thinking it was almost done. Took 2 years and plenty of 0.99 patches to...
There are also the cautionary tales of jumping too far quickly, for example Linus Torvalds went from 0.12 to 0.95 of Linux, thinking it was almost done. Took 2 years and plenty of 0.99 patches to get to 1.0.
Huh, that's an interesting one, I didn't know that - perils of being one of the people figuring things out right at the start, I guess! Or perhaps a statement on Torvalds' opinion of himself, if...
Huh, that's an interesting one, I didn't know that - perils of being one of the people figuring things out right at the start, I guess! Or perhaps a statement on Torvalds' opinion of himself, if some of his comments to other devs over the years are anything to go on... Probably a bit of both.
And now he just increments the major number when the minor number hits somewhere around 20. I remember in 2019 he delayed 5.0 just so we could get patch 4.20!
And now he just increments the major number when the minor number hits somewhere around 20. I remember in 2019 he delayed 5.0 just so we could get patch 4.20!
I admitedly don't know how versioning works. But Neovim must be one of the most complete and realiable
0.12program out there.I don't reallly use it anymore though. I understand Lua is a treat to programmers, but I'm not one. It completely removed my joy when interacting with Neovim. I just use Emacs for that stuff now. I'm pretty sure they will never change its configuration language.
Based off the 3 version numbers
0.12.0it seems they use semantic versioning, which divides the 3 version numbers into MAJOR.MINOR.PATCH. Major versions are supposed to be breaking changes, minor upgrades that are backwards compatible and patches for bugfixes only.This versioning scheme makes the most sense for libraries, i.e. code that is meant to be used by other code, because you can tell at a glance if you as the user of such libraries need to change something. Minor and patch versions are drop in replacements, major require some changes on your end to get your code to work again.
This is really just the idea, and nothing says that you have to adhere to these rules. Sometimes software increments the major version if some new big feature is getting released.
It’s a meme, but there’s also a pretty large kernel of truth in most semver projects actually incrementing based on how proud the developers are of a given checkpoint. In my experience it also maps to the fact that deep fundamental unix packages like this never hit a 1.0 release - the kind of mind that’ll work on a fork of a reimplementation of a terminal text editor from 1976 and do a damn good job of it is never satisfied with their own work!
There are also the cautionary tales of jumping too far quickly, for example Linus Torvalds went from 0.12 to 0.95 of Linux, thinking it was almost done. Took 2 years and plenty of 0.99 patches to get to 1.0.
Huh, that's an interesting one, I didn't know that - perils of being one of the people figuring things out right at the start, I guess! Or perhaps a statement on Torvalds' opinion of himself, if some of his comments to other devs over the years are anything to go on... Probably a bit of both.
And now he just increments the major number when the minor number hits somewhere around 20. I remember in 2019 he delayed 5.0 just so we could get patch 4.20!
Whether they'll ever reach it is an open question, but there are plans for a Neovim 1.0 release.
With this release, Neovim now has a built-in package manager: Pack