Consider using semver for releases

[typeoneerror]

Breaking Change: We have removed otherModesKeyBindings configuration. In its stead we have added: normalModeKeyBindings and visualModeKeyBidnings to allow more fine-grain customization of your remappings. For more information, see our documentation.

It'd be great if you could start following semver conventions for your releases, specifically not releasing breaking changes as a minor release. From semver.org:

MINOR version when you add functionality in a backwards-compatible manner, and

Maybe work towards a 1.0 release and then adopt this methodology. I suppose this also might be a VS Code problem since I don't think you can specify to only upgrade to a certain release...auto-update is either ON or OFF.

[jpoon]

Yes, absolutely. I was debating bumping it to 1.0 when we introduced the breaking config change, but I don't yet feel like this extension is at that v1.0 point, but then again...when is any software project ever really "ready".

I suppose this also might be a VS Code problem since I don't think you can specify to only upgrade to a certain release...auto-update is either ON or OFF.

That is correct. It's an auto-update. Although, when we DO adopt semvar, I hope that when people see a major release rev, people can expect that some things might be broken (probably with their configurations) cause that's really the only state that lives across versions.

[johnfn]

Just to be obnoxious, semver says that anything under version 1 can introduce breaking changes at any time:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

I understand that it is frustrating to have breaking changes in new VSCodeVim releases, however. That's definitely something we can keep in mind. Plus, VSCodeVim is probably popular enough to not be considered "under initial development" any more.

[jpoon]

Just pushed v1.0.0. We'll start following semver now.