On Mon, 4 Apr 2016, Bram Moolenaar wrote:
I have been wondering if the next release should be called 7.5 or 8.
I'm inclined to think it should be version 8.
Hi Bram,
2016/04/05 5:13 "Bram Moolenaar" <Br...@moolenaar.net>:
>
> I have made a list of the most important improvements compared to Vim
> 7.4. I might still be missing some (let me know!).
maybe the following features are missing.
* Packages
* Emoji support
* GTK 3 support
2016/4/5 Tue 5:13:23 UTC+9 Bram Moolenaar wrote:
> I have made a list of the most important improvements compared to Vim
> 7.4. I might still be missing some (let me know!).
I want to list two features:
* DirectWrite (DirectX) rendering support on MS-Windows:
It improves the quality of text rendering drastically.
* The breakindent patch:
It took 10 years to be merged. Wow!
Another notable thing (but not a new feature) is the nightly builds.
https://github.com/vim/vim-win32-installer
Regards,
Ken Takata
Am Dienstag, 5. April 2016 09:28:34 UTC+2 schrieb Dominique Pelle:
> Here are some patches that I vote for, for the next version,
> taken from todo.txt:
>
If I could wish, I would like to see my personal favorit added.
Its realy useful and avoids a brothersome tmp file in daily work:
Patch to add the :bvimgrep command. (Christian Brabandt, 2014 Nov 12)
Updated 2016 Feb 10
I actually think 8.0 makes sense, due entirely to expected plugins that will require the new features.
Considering any plugins that start to require the new packages feature, IO/jobs/channels features, etc. may not work AT ALL in older Vims (instead of just degraded performance) I think it makes sense to let them say "requires Vim 8.0 and up".
Although Vim kept backwards compatibility, it introduced a bunch of features that will be hard to embrace fully in plugins and yet remain backwards compatible with older Vims.
Vim 8, also please adopt a sane version number policy after this release, vim 7.4.1689-1 is starting to look a bit silly.
Especially the last huge number at the end.
I informally think of Vim by putting the patch number as a third minor version, similar to the "Semantic Versioning" standard (http://semver.org/) that we use at my place of employment.
For example, instead of "Vim 7.4, patches 1-1726," I mentally think, "Vim 7.4.1726".
Maybe it's time to make this an official nomenclature?
This does break the model where some people selectively cherry-pick patches, and use something like, "Vim 7.4 with patches 1-5,9-33,1024-1726." In the "old days", sometimes people lacked quality Internet access to the old CVS repository and would have to manually patch their Vim source code from the emailed diffs. If they were only concerned with Vim on a given architecture, they could theoretically skip patches that didn't apply to them.
I would argue that number one, this is NOT a good idea, because the source code changes are cumulative. Trying to do regression testing on 7.4 plus every combination of the current 1726 patches would be nearly impossible to implement and manage. I think you should always apply ALL the patches, even the ones that might not apply to your situation, just to avoid side effects.
Number two, I don't think this use case still applies. I doubt that very many people still download a tarball of the Vim 7.4 source code, and then manually apply each and every diff based on the email attachments from Bram. I could be wrong, but Internet access is more common now, and ever since we switched to first Mercurial and now Git it has become very easy to get the latest "snapshot" of the code.
Finally, this is just a hunch, but I bet most maintainers that bundle Vim for various operating systems just bundle up the latest stable patch release when they do a freeze.
So I do not have a strong opinion on whether or not we call the next generation version 7.5 or 8.0. I do, however, think we should start appending the patch level as the third "minor" release number.
Thoughts?
-maj