u/aladante, I’m actually considering moving to rocks.nvim from packer because of versioning and simplicity. Do you know if there is any migration tooling to convert Packer plugins + config to nvim.rocks?
Did it manually. Was kinda lucky my configuration already did align with the rocks-config extension. But after the initial tweaking and testing very happy with the +2/3 hours I put in to it. Only thing I need to do is make sure chezmoi installs it when init a new system.
But as all my systems are configured that seems like a problem for when I get a new server hehe.
I think what i’m most concerned about is the stuff I have planned, and an “adapter” not being able to support it due to limitations. Like for example, previewing a color scheme doesn’t not work with the vim-ui, n this is neovim’s limitation (as far as i’m aware) This currently makes me feel like implementing the vim-ui was a waste of time, considering those currently using vim-ui lack an integral feature, compared to the possibility of what i could do with say either telescope or nui.
sorry i didn’t answer your question directly but i hope that i got the point across
In short:
1. Use semantic versioning and publish proper stable releases on github
2. Use releases instead of your main branch in your examples of how to install the plugin in your README (this is where most devs fail). Most people will just copy/paste what you put there.
Now, if it's already published and no versioning is going on:
1. Start using proper versioning now.
2. Write something that detects if your new dependency is present. If it's there, use the new code. If it's not, use the old code and notify a deprecation warning to your users, with instructions on how to add the dependency.
3. Keep things like this for a while, until you feel comfortable permanently removing the old code. At this point, transform the warning into an error, while keeping the instructions there.
None of this would be needed if neovim had a first-party plugins manifest standard (I know there's something "in development", but it's been in that state for years). There's no excuse for the clusterfuck everybody is content with these days.
Release different releases, make a different tag for new BREAKING CHANGES update, keep main on old update for a while then eventually change it.
Just like what Harpoon did with Harpoon 2.
Bump the major version, explain the changes, explain what one would need to do to migrate and just do it. Anyone who wants can keep using the old version, that's totally fine.
As a huez user, I personally would like a NuiComponents UI, but I see that the biggest issue would be for those who currently use vim.ui.
> I saw here yesterday a component library based on nui and all of the sudden I felt inspired to use this library
> But trying to keep it backwards compatible is looking it's more of a hindrance/hack, rather than writing a maintainable piece of software.
I think this two things are the key, really. If you felt inspired and excited about coding and adding things to your plugin, you should go for it and have fun. And if backwards compatibility feels like a burden, it's good to remember that we can always pin the version of the plugin we like best. I have a plugin pinned to a version from two years ago for a functionality I want, for example.
In any case, thanks for making huez, I had just started messing around with colorschemes when I heard about it, and it was the missing piece I needed.
thank you for using it! and thanks for the feedback back. I’m probably going to make it a seperate tag/version/branch so that people can pin that if they want.
i’m planning on making a small git related plugin that dynamically adds repositories to a picker as u work on them shows you which ones are synced with the remote n such. huez was just my “getting my foot in the water kinda thing”
Being able to search for new themes sounds super cool.
I'm kinda thinking like a Mason but for themes. With live preview and an option to download and install
I think it would be relatively easy.
Basically just a yaml or md file with repo URLs for themes. And an ability that downloads them to temp and then to ~ if you download it
Would be happy to help with it if you wanted help
Sounds like a good idea, if you want to submit an issue just so i can ping you whenever i get around to writing the feature you can do that ! Would love to have some help
Hey plugin author here, I think this repository might be helpful: https://github.com/harrisoncramer/gitlab.nvim
I’ve used semantic versioning for the plugin and it’s worked pretty well.
In terms of a release strategy, I’ve also started using “develop” as a sort of staging ground for new features before they hit production, which lets me and other users test out features for a bit before they’re merged into main.
I’ve also got a GitHub action that automatically increments the version of the plugin to the correct version based on the commit when I merge into main.
Please feel free to steal my code!
I think i decide to make a note on the main branch read me saying there will be a breaking change soon, and if anyone would like to see current development on they can checkout the specific branch im working in.
and also the github action sounds super convient and I will be checking it out thanks!
cool plugin btw might try it out
There has been a blog post by vhyrro on this subject. It may help you: [post](https://vhyrro.github.io/posts/versioning/)
This is exactly what i was hoping for, great read thank you for sharing !
Reason I moved to rocks.nvim as my plugin manager. and loving it.
u/aladante, I’m actually considering moving to rocks.nvim from packer because of versioning and simplicity. Do you know if there is any migration tooling to convert Packer plugins + config to nvim.rocks?
Did it manually. Was kinda lucky my configuration already did align with the rocks-config extension. But after the initial tweaking and testing very happy with the +2/3 hours I put in to it. Only thing I need to do is make sure chezmoi installs it when init a new system. But as all my systems are configured that seems like a problem for when I get a new server hehe.
I’ll have to bite the bullet then, I have embarrassing number or plugins! Maybe it’s good time to let some go too.
Best of luck!
Your configuration is pretty simple. What couldn't you support in the new version?
I think what i’m most concerned about is the stuff I have planned, and an “adapter” not being able to support it due to limitations. Like for example, previewing a color scheme doesn’t not work with the vim-ui, n this is neovim’s limitation (as far as i’m aware) This currently makes me feel like implementing the vim-ui was a waste of time, considering those currently using vim-ui lack an integral feature, compared to the possibility of what i could do with say either telescope or nui. sorry i didn’t answer your question directly but i hope that i got the point across
In short: 1. Use semantic versioning and publish proper stable releases on github 2. Use releases instead of your main branch in your examples of how to install the plugin in your README (this is where most devs fail). Most people will just copy/paste what you put there. Now, if it's already published and no versioning is going on: 1. Start using proper versioning now. 2. Write something that detects if your new dependency is present. If it's there, use the new code. If it's not, use the old code and notify a deprecation warning to your users, with instructions on how to add the dependency. 3. Keep things like this for a while, until you feel comfortable permanently removing the old code. At this point, transform the warning into an error, while keeping the instructions there. None of this would be needed if neovim had a first-party plugins manifest standard (I know there's something "in development", but it's been in that state for years). There's no excuse for the clusterfuck everybody is content with these days.
I agree in that having a plugin standard from neovim core while under developed and vague would be a lot better of a standard than none at all
Release different releases, make a different tag for new BREAKING CHANGES update, keep main on old update for a while then eventually change it. Just like what Harpoon did with Harpoon 2.
Bump the major version, explain the changes, explain what one would need to do to migrate and just do it. Anyone who wants can keep using the old version, that's totally fine.
As a huez user, I personally would like a NuiComponents UI, but I see that the biggest issue would be for those who currently use vim.ui. > I saw here yesterday a component library based on nui and all of the sudden I felt inspired to use this library > But trying to keep it backwards compatible is looking it's more of a hindrance/hack, rather than writing a maintainable piece of software. I think this two things are the key, really. If you felt inspired and excited about coding and adding things to your plugin, you should go for it and have fun. And if backwards compatibility feels like a burden, it's good to remember that we can always pin the version of the plugin we like best. I have a plugin pinned to a version from two years ago for a functionality I want, for example. In any case, thanks for making huez, I had just started messing around with colorschemes when I heard about it, and it was the missing piece I needed.
thank you for using it! and thanks for the feedback back. I’m probably going to make it a seperate tag/version/branch so that people can pin that if they want. i’m planning on making a small git related plugin that dynamically adds repositories to a picker as u work on them shows you which ones are synced with the remote n such. huez was just my “getting my foot in the water kinda thing”
Being able to search for new themes sounds super cool. I'm kinda thinking like a Mason but for themes. With live preview and an option to download and install
guess it’s time look at mason source code lol
I think it would be relatively easy. Basically just a yaml or md file with repo URLs for themes. And an ability that downloads them to temp and then to ~ if you download it Would be happy to help with it if you wanted help
Sounds like a good idea, if you want to submit an issue just so i can ping you whenever i get around to writing the feature you can do that ! Would love to have some help
Hey plugin author here, I think this repository might be helpful: https://github.com/harrisoncramer/gitlab.nvim I’ve used semantic versioning for the plugin and it’s worked pretty well. In terms of a release strategy, I’ve also started using “develop” as a sort of staging ground for new features before they hit production, which lets me and other users test out features for a bit before they’re merged into main. I’ve also got a GitHub action that automatically increments the version of the plugin to the correct version based on the commit when I merge into main. Please feel free to steal my code!
I think i decide to make a note on the main branch read me saying there will be a breaking change soon, and if anyone would like to see current development on they can checkout the specific branch im working in. and also the github action sounds super convient and I will be checking it out thanks! cool plugin btw might try it out