search

nvimtools / none-ls.nvim

null-ls.nvim reloaded / Use Neovim as a language server to inject LSP diagnostics, code actions, and more via Lua.
The Unlicense
2.58k stars 83 forks source link

Possibility of having changelog. #2

Closed eshepelyuk closed 9 months ago

eshepelyuk commented 1 year ago

Is it possible to start maintaining some sort of changelog / version history / release history ?

mochaaP commented 1 year ago

Keeping a clean commit log is the best changelog, in my honest opinion. :P

If we really need a release history, we should also consider when to do a stable release (monthly?), as the development cycle is rolling quick for such a project.

smjonas commented 1 year ago

Release-please could be used to allow versioning of this plugin and it can generate a changelog as well. See e.g. folke's lazy.nvim.

mochaaP commented 1 year ago

If we release a version just within a few commits, then I couldn't see the point of doing this. In the case of avoiding breaking changes, I'd rather prefer to develop that on a different branch and transition to it gracefully. I encourage the state of "if you believe something is wrong, open a PR" instead of pinning to "stable" commits.

jay-babu commented 1 year ago

https://github.com/jay-babu/mason-null-ls.nvim/blob/main/.github/workflows/ci.yml#L37 - versioning seems like another headache for maintenance but using this github workflow, I would recommend it as it just involves merging a pull request when ready to release. the version numbers are handled for you

jakenvac commented 11 months ago

With main being the source of truth and pull requests being squash only, as long as we keep healthy commit messages, the git log is the change log.

As @jay-babu mentioned, versioning is also another factor to consider. But again with this workflow, our commit hashes are essentially version numbers.

If we were ever to need sequential version numbers, it would make sense to use CalVer as we don't need to worry about things like patch increments and breaking changes. (As mochaaP said, using a different branch for these kinds of changes is a good approach for breaking changes. Especially in the nvim ecosystem)

Given the current development & release practices, I'd suggest this issue could be closed.

ambroisie commented 11 months ago

Rather thank ask for a changelog, it would be nice to do like some other plug-ins and create a (locked) issue which gets updated with a new comment when a breaking change is merged in.