[vim/vim] Can we please reduce the "churn" in the winget published package? (Issue #11784)
Mihai Nita
Steps to reproduce
Description
winget is a Windows command line package manager offering functionality similar to apt-get on Linux, or homebrew on MacOS.
Vim is published in the winget packages repo, which is very nice and I do appreciate it.
But it looks like what is published is a daily build, similar to what is tagged here, in github.
(https://github.com/vim/vim/tags)
That is way too often, to the point of being annoying.
Imagine that an apt-get upgrade would update your Linux vim every single day.
Does anyone really need to be at the bleeding edge, every single day?
See here the winget packages: https://github.com/microsoft/winget-pkgs/tree/master/manifests/v/vim/vim
Reproducing it:
Using in Windows install vim:
winget install vim.vim
Then every day try to update it:
winget upgrade vim.vim
There will be an update almost daily.
Are there any milestones that are more important than others?
Something reflected in the version (which seems to be semantic, in some way)?
Or every 10 / 20 / 30 builds?
If not, then maybe publish separate packages (vimdaily, vimweekly, winmonthly?)
Compare to the frequency on homebrew (looks like weekly?) (https://formulae.brew.sh/formula/vim):
https://github.com/Homebrew/homebrew-core/commits/master/Formula/vim.rb
Note that it is a common practice (on systems with a package manager) to periodically update everything.
The "update everything except vim" option is not as convenient.
Instead of winget upgrade --all one would have to run winget upgrade foo bar baz pack1 pack2 and so on
(everything but vim). And you would need to keep that list of packages up to date by hand.
(there is no winget option to say update all except a,b,c)
And "don't update that often" is also not as convenient. In fact it can be dangerous.
Now one would potentially use a vulnerable app (imagine Chrome) for a week (or more).
Thank you very much,
Mihai
Expected behaviour
Get updates only for more important releases.
I don't know what are the vim rules for the semantinc versioning.
Version of Vim
all
Environment
Operating System: Windows
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Does anyone really need to be at the bleeding edge, every single day?
I need, although I don't update it everyday, I want to be able to get fresh version of vim on Windows with all the recent patches applied.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mihai Nita
I hear you.
But you are a contributor to this repo.
You are invested in this project more than most.
Yes, there are probably many others like you, I'm sure you are not alone.
But I promise you there are also many like me.
I didn't say "let's kill the nightly", but "can we accommodate both kind of users?"
There are quite a few packages doing this.
Some examples:
Neovim.NeovimandNeovim.Neovim.NightlyGIMP.GIMPandGIMP.GIMP.NightlyVideoLAN.VLCandVideoLAN.VLC.NightlyMozilla.Firefox,Mozilla.Firefox.Beta,Mozilla.Firefox.Nightly
(you can try winget search ".beta" or winget search ".night" for more)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### Steps to reproduce
>
> **Description**
>
> [`winget`](https://github.com/microsoft/winget-cli) is a Windows command line package manager offering functionality similar to apt-get on Linux, or homebrew on MacOS.
>
> Vim is published in the winget packages repo, **which is very nice and I do appreciate it**.
> But it looks like what is published is a daily build, similar to what is tagged here, in github.
> (https://github.com/vim/vim/tags)
>
> That is way too often, to the point of being annoying.
> Imagine that an `apt-get upgrade` would update your Linux `vim` every single day.
> Does anyone really need to be at the bleeding edge, every single day?
>
> See here the winget packages: https://github.com/microsoft/winget-pkgs/tree/master/manifests/v/vim/vim
>
>
> **Reproducing it:**
> Using in Windows install `vim`:
> ```
> winget install vim.vim
> ```
> Then every day try to update it:
> ```
> winget upgrade vim.vim
> ```
> There will be an update almost daily.
>
> Are there any milestones that are more important than others?
> Something reflected in the version (which seems to be semantic, in some way)?
> Or every 10 / 20 / 30 builds?
> If not, then maybe publish separate packages (vimdaily, vimweekly,
> winmonthly?)
automate it, e.g. make a weekly package every Wednesday, then I'm sure in
some weeks it's missing some patch that was made just after it, and we
might have to make an extra one.
It's a lot simpler to handle this on the installer side: Just make a
daily package and you decide when you'll get it. So you can get it on
every Wednesday. But when something is missing, you can get next day's
package. This takes away a lot of work on the distribution side.
Do not underestimate how much effort goes into planning releases. It's
alway a lot of discussion, and then usually an hour after the release a
problem is found and the release needs to be updated.
> And _"don't update that often"_ is also not as convenient. In fact it
> Now one would potentially use a vulnerable app (imagine Chrome) for a
> week (or more).
Many "professional" apps are only updated infrequently, it may take one
or two months. For Chrome, when there is something so serious it's in
the news, they usually have a new version almost immediately. But the
regular updates (I believe these come every six weeks) usually fix a
dozen security issues.
--
Kiss me twice. I'm schizophrenic.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Christian Brabandt
The packages are automatically submitted using https://github.com/vim/vim-win32-installer/blob/master/.github/workflows/winget.yml
I would say, don't worry, as long as no-one complains for taking too many resources (disk space) just upload every nightly also to winget, because you may not be particular interested in a feature that 9.0.XXXX bring, but several other users may be waiting for that one for some time.
Same thing with potential security relevant issues. They should be uploaded and distrubted to users as fast as possible.
So the more important question would be: how can we determine when to release a new version to winget? I think this is much more harder to answer and therefore I would really prefer to keep the existing scheme, even so that means, you may have to update your vim every day.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mihai Nita
I would say, don't worry, as long as no-one complains for taking too many resources
I am actually complaining, as a user of vim :-)
I am running winget update daily, because I want security updates as fast as possible.
But I don't care to get every single typo fix as fast as possible.
To the point where I am considering switching to neovim, which separates the nightly builds.
I would rather not, but I am kind of getting tired to see vim updating every day.
Consuming time and attention (because I don't just update "blindly", I keep an eye on the outputs to see what is installed)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Nick Jensen
Since, as @chrisbra has pointed out, the winget packages are not generated from this repo but from vim/vim-win32-installer, perhaps you could submit a PR over there, to add a "Vim Stable" winget package as a manual pipeline action.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mihai Nita
Thank you,
I can take this to vim/vim-win32-installer, and contribute a PR.
But I don't see any obvious way to differentiate between the nightly releases and "Stable" ones.
Is major + minor version a decent indicator?
"Stable" would be any change in minor version?
Because if the normal development cycle does no have concept of "stable", then releasing such a thing would be artificial / not that useful (for example, does a fix for a major security / crash bug trigger a minor version update?)
Thanks,
Mihai
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
We do not have a concept of stable.
But I suppose the following could work:
- Change winget.yml and change the Package Identifer to something like Vim.Vim.Nightly and possibly rename winget.yml to
winget_nightly.yml - Create a new
winget.ymland add aCron Schedulethat runs like once every week:
on:
schedule:
- cron: '0 0 * * 0'
and I believe this should work with winget packages then.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ben Jackson
FWIW homebrew's (questionable?) approach is to only update every 50 patches.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Thank you,
>
> I can take this to [vim/vim-win32-installer](https://github.com/vim/vim-win32-installer), and contribute a PR.
>
> But I don't see any obvious way to differentiate between the nightly releases and "Stable" ones.
> Is major + minor version a decent indicator?
>
> "Stable" would be any change in minor version?
> Because if the normal development cycle does no have concept of "stable", then releasing such a thing would be artificial / not that useful (for example, does a fix for a major security / crash bug trigger a minor version update?)
releases, the next one would be 9.1. But those only happen very
infrequently, say once per year.
Actually planning a stable release once in a while both make development
more complex (would require postponing including some patches) and gives
a false idea of that these releases would be better than others. The
only way would be to take a version and not apply any changes for about
a week, while making sure many users try it out. A kind of "beta"
version. This is complicated, many users would wait until that week is
over and grab the resulting "stable" version, and only then report any
problems. Or we have a last-minute patch that we really want to
include and should be safe, and it turns out it causes problems. Both
have happened in the past.
The current way of fixing any reported problems quickly means that most
"nightly" builds are good. Once in a while there might be a bad one,
but it is unpredictable when that happens. Perhaps it's possible to
withdraw a build if we find out that it has a problem affecting more
than a few users? I don't see how that helps. E.g. if you get a
nightly build once per week, how do you know it was marked as bad and
should get the build made a day later?
--
hundred-and-one symptoms of being an internet addict:
27. You refer to your age as 3.x.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
GolarM
I've already made the script that filtered version numbers of signed packages out.
That is already ~10 times fewer updates than nightly.
Can you add vim.vim.nightly.sig channel for that matter?
Looks like a differentiation that could be useful for less frequent updates.
It should take to add another list with fewer items.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
It is there since vim/vim-win32-installer@f25a6ae
Let me close it here and if there is anything, please open a new issue in vim/vim-win32-installer okay?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #11784 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.