You must log in or register to comment.
while I really like this idea, I lean toward thinking it’ll be too inconsistent for the plugin community at large to implement unless there’s some kind of soft enforcement from plugging managers. even now there are so many plugins that have just a few commits with a small readme marked as alpha; I’m not sure that enough people would follow these branch conventions until it’s super easy to do
That’s a good point. However, if it is the case that the most popular plugins are the ones predominantly introducing disruptive breaking changes, then you just need these plugins to follow the proposal. And then, you get control over, say 80% of the disruption, even with relatively limited adoption. In my experience, these popular extensions tend to have a fairly thorough readme, even wikis and community discussions sometimes, so they might be keener to also follow this kind of practices.
Case in point, telescope.nvim even has releases, so they clearly care about providing more stable snapshots.
Further reading the telescope release notes:
With this release we also introduce a new release branch 0.1.x which will get constant fixes, performances improvements and new features without breaking backwards compatibility, so we kindly ask you to switch to either the fixed 0.1.0 tag or this release branch.
Seems relatively close to the proposal.
I really like the idea of this, and I go back and forth on this at times.
Philosophically, I think there is certain benefit to separating source-code from the idea of release artifacts, which makes me lean toward using an artifact repository for version management, rather than source-control.
Somewhere in the middle, there are tools that shoe-horn Git into being an artifact repository by abusing LFS, which I find intriguing. See gpm, for example.
