Please sync rollouts and github releases

[jeffschwartz]

I just installed 0.6.15 but when I pull up releases on Github I see the following:

I expect to see the release matching the one I am installing but as you can see they differ.

This has been the case for a while now and it makes it difficult if not impossible to know anything about the scope of changes in the version I installed. So please post the release to Github prior to pushing the update out for consumption.

In addition, I think it would be really great if there was an actual change log :)

BTW, VSCodeVim is fantastic and thank you to all the contributors involved.

[johnfn]

The release notes ARE the changelog. Hence why they link to the release notes. 😉

Updating the changelog is a boring and manual process, which often competes with going to bed for our attention. :) Which is why we sometimes skimp. To be fair, most of the time when we do skip out on the changelog, it's just a very trivial bug fix, as it was in this version.

I'm going to close this issue, but the request for a clearer and more up to date changelog has been heard. Thanks!

[jeffschwartz]

Thanks @johnfn for the speedy reply. What release notes are you referring to if you don't mind me asking? My concern -- I probably could have been clearer :) - is that when VS Code informs me that there is an update more often than not there isn't a tagged version for the release and going to the release tab on github shows that the latest release is older than the one VS Code is showing me for updating. I hope that clarifies my intention if I failed to do so initially.

I will frequently pass on plugin updates if there isn't any or enough information provided as to what they contain. Maintaining a stable environment for development, as I am sure you would understand, is very important to me and I would guess to others as well. A change log most definitely would suffice to provide that information but in lieu of that a tagged version with comments on the github releases tab will also do.

Thanks again to all the dedicated maintainers of this awesome Vim plugin for VS Code.

[jeffschwartz]

Here @johnfn is a current example of what concerns me. Below is a screen shot of the Changelog tab in VSCode plugin manager for the plugin. Notice that the version installed is currently 0.6.15:

When I click on the "Please click here for our changelog" link it takes me to the release tab of the plugins repo and currently the latest release posted is 0.6.13 which is older than the one I have installed:

So without a changelog and no tagged version for the update where then can I find the details of the update?

[xconverge]

@jeffschwartz yea understood, in all honesty, this usually happens when there is a bad bug that the tests did not catch. We do an ideal release with some decent notes, then within a day or so, if a bunch of users report something critical that regressed and the tests did not catch, there may be 1 or 2 hotfix releases to fix the critical issue. We could easily just add a line saying "fixed this critical issue, hotfix release", but are usually more focused on getting it released to maintain the status quo of peoples development.

We also add the .vsix extension to the releases, so that if you happen to update and something is completely broken for YOU, you can install the version you were using before and ignore updates for a few days or weeks until you trust us again :)

It is easy to solve, improve the release notes :)

[xconverge]

I just generated this changelog with https://github.com/skywinder/github-changelog-generator

Thoughts? I think it actually looks pretty good for something auto generated...

Here was my autogenerated changelog:

https://markdownshare.com/view/8b238cf5-2f01-47c0-bc9f-2bb190d4cb61

I pasted it into this issue at first and now it referenced every single issue to this issue, oops..

[johnfn]

Yeah I mean if you guys are okay with autogenerated release notes, then maybe I have been overthinking things. I didn't want to do that because I didn't think you'd be able to read them well, but hey, if they're actually okay...