FR: more frequent releases

[chrisgrieser]

Status quo
This plugin has a somewhat peculiar release situation due to its rust binary, standing out from regular lua plugins. To install this plugin, you need one of the following

1. Install rust tool chain and build yourself → tracks latest changes
2. Install the plugin with tag = "v0.* and have the plugin download the compiled binary for you → stays on last stable version
3. Install the plugin without tag =, and use fuzzy.prebuilt_binaries.force_version. This allows you to track the latest changes without having to build yourself, but can break the plugin.

In effect, this situation results in far more people using tag = for this plugin than with other nvim plugins.

Problem 1
However, since the plugin is still somewhat beta quality (as stated in the readme), a tagged commit does not mean yet that that version is mostly bug free. If I want to include a bug fix that was merged after the last tagged release (e.g., #194), the release situation means that I need to build the rust binary myself. (main + fuzzy.prebuilt_binaries.force_version = "v.0.5.1" currently errors.) Building yourself can/should be expected from people who like living on the cutting edge / don't mind beta-testing. But building yourself should not be required if you prefer to be on a more stable version.

Problem 2
The readme refers by default presented to a new user is based on the main branch, while at the same time, users are most likely being on the last tagged commit. Thus, they will refer to a version of the readme which will include changes not applicable to their version of the plugin. While technically solvable by the user by opening the readme at the latest tagged commit, this is not something many users will be aware of (and also easy to forget even as an experienced user).

Problem 3
If I notice a bug and want to report it, there is a good chance it was already merged in one of the ~70 commits since the last tagged commits. This means a higher likelihood of unnecessary bug reports. Alternatively, this means that before I open a bug report, I basically have to build the plugin myself, to ensure the bug is still there are the latest release. This is quite cumbersome, and will potentially deter people from reporting bugs.

Suggested Solution

• Release more frequently. Can't really say how often, but right now, the last tagged release is ~70 commits / more than 3 weeks ago, which feels a bit long.
• Problem 2 might also be addressed by simply not displaying the main-branch readme on the repo's landing page. (for which there are various methods like using a dev branch, using a separate readme file, etc.)

[Saghen]

Thanks for writing this up! I've been meaning to release a new version for a while, just hadn't gotten around to it since I wanted to document the new draw code before I did. Just got around to that and released a new version, sorry for the wait!

While technically solvable by the user by opening the readme at the latest tagged commit, this is not something many users will be aware of (and also easy to forget even as an experienced user).

I've included a note at the top of the README which points to the latest release for now but I'm not a huge fan of this. Eventually, I'll host the documentation elsewhere (i.e. GitBook) which will solve this more elegantly.

Problem 1 and 3 are solved by releasing more often, which I intend to do :)

[chrisgrieser]

thank you 🩶