[vim/vim] Why add a patch number and tag to nearly every commit? (Discussion #12795)
Kevin Cummings
I'm sorry, I'm sure this has been asked hundreds of times, but I can't find the answer when googling.
Why add a patch number and tag to nearly every commit? What's the reasoning? Thanks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
Just from my perspective, Vim doesn't really have a real release cycle. While there are minor version updates like 8.1, 8.2, 9.0, there could be years between each minor release, and it has always been a little arbitrary when that happens. As such, you could better think of Vim as essentially having a rolling release model where every commit is its own release and package managers would just pick one and package it. For example, if you look at how Homebrew (a macOS package manager), their Vim definition just picks nice round numbers like 9.0.1700 and updates the package after every 50 or 100 patches.
As a downstream maintainer (MacVim) myself, this does mean you can always just pick the latest version of Vim, but it does add some caveats because Vim could at times be unstable and since it doesn't have a proper release models, it's up to you to find out which release is the stable one and which one has some WIP unstable changes.
Why add a patch number and tag to nearly every commit? What's the reasoning? Thanks.
I think a better question is why do you have this question? It's easier to answer questions when you provide the contexts and rationale for asking the question.
I think the current patch number system reflects the way Vim is developed and released. If the contention is that its release model is suboptimal, then I think the release model is the issue and there are valid discussions of whether Vim should adopt a proper release cycle (e.g. Neovim does have proper minor version releases but it usually only takes a couple months before Neovim releases a new version instead of taking years). If your issue is that patch numbers are too large (in the thousands), I personally it's kind of a non-issue personally. There are no meanings behind the numbers other than one is larger than the other.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kevin Cummings
After I heard Bram died I wondered if development of Vim would continue so I started watching the commits. That's when I noticed the patch numbering. It was just curiosity, not criticism.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
Note also that it is useful and can be necessary to check has(patch) or similar for code to work properly. (Many people just program against the bleeding edge, myself often included for my plugins, but not all).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ObserverOfTime
Bram used to do it that way and it was decided that, at least for the time being, it will continue.
The only major difference is that runtime updates are no longer bundled together.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.