handling `dev` `version`s and basic rolling release workflows

[mrcjkb]

I noticed that the current iteration of the readme states that plugin authors should have a tag that matches the version in the packspec.

Just wanted to bring it to your attention that some plugin authors may disagree with this.
See for example ibhagwan/fzf-lua#640 (comment).

Others might want to keep a dev or scm version on their main branch.

With RockSpec, this is handled in a variety of ways. Often, the main branch has a RockSpec with version = scm, and there's a subdirectory with version-named rockspecs.

An alternative approach could be to allow the semantic version only on tags or stable branches.

[mjlbach]

Just wanted to bring it to your attention that some plugin authors may disagree with this. See for example ibhagwan/fzf-lua#640 (comment).

Part of the point of standards is pushing people for homogeneity for the benefit of users and writing simple package managers. I was aware when I wrote this that there would be a few outliers.

Anyways, I'm not involved with neovim anymore so this repo is effectively dead, as it was one of my passion projects

[mrcjkb]

Part of the point of standards is pushing people for homogeneity for the benefit of users and writing simple package managers.

I believe supporting scm versions would benefit plugin authors as well as users who like to be on the bleeding edge.
But I see your point that it could make package managers more complicated.

Anyways, I'm not involved with neovim anymore so this repo is effectively dead, as it was one of my passion projects

That's a shame to hear. It seems like others have been continuing work on this though?

Thanks for your previous work on neovim 😄

[lewis6991]

This repo is on a long hiatus. The main blocker was getting package managers to prototype something.

I've been spending most of my time on Neovim core for the last year or so but I do plan to pick this up again at some point.