Open HeitorAugustoLN opened 4 weeks ago
These all look like very good suggestions to me. The stable release branch is the only one I'm a little unsure about since it would take quite a lot of work, but I can see the issue we have without support for this as well, so I'd be OK with it :)
These all look like very good suggestions to me. The stable release branch is the only one I'm a little unsure about since it would take quite a lot of work, but I can see the issue we have without support for this as well, so I'd be OK with it :)
Thanks for the feedback! I get your hesitation about the stable release branch, it does sound like a lot of work. But I don’t think it'll be too crazy. The biggest part is just checking if changes are backward-compatible, and after that, we can just use the backport workflow I set up in #383 to handle the rest. Shouldn’t be too bad! 😄
Adopt Conventional Commits: Transition to using conventional commit messages in the format:
[optional component]: .
If I may provide my two cents here: I really dislike the standard "conventional commit" messages which include the type
. Often, commits won't necessarily conform to a specific category, and repos using conventional commits often end up just having chores
and feats
everywhere, even for things like refactors or releases, which does nothing but clutter the git history.
Since this is a Nix project, why not adapt the Nixpkgs commit conventions?
If I may provide my two cents here: I really dislike the standard "conventional commit" messages which include the
type
. Often, commits won't necessarily conform to a specific category, and repos using conventional commits often end up just havingchores
andfeats
everywhere, even for things like refactors or releases, which does nothing but clutter the git history.Since this is a Nix project, why not adapt the Nixpkgs commit conventions?
Nixpkgs commit convention would also be good. But it wouldn't really help that much with versioning, and I really like the type
in conventional commits. And it wouldn't be generally a problem here, because most of the commits are new features or fixes. But nixpkgs commit convention would not be a bad idea also.
Feedback and suggestions on these proposed changes are welcome :)
General
[x] Adopt Conventional Commits: Transition to using conventional commit messages in the format:
<type>[optional component]: <description>
. This will make commit messages clearer, especially longer ones like 7fb80fea2373c3cc9f05a84204ad0b3233464b17, and will streamline versioning efforts (see #175).[ ] Standardized Issue and Pull Request Templates: Introduce templates for issues and pull requests to provide a consistent format for contributors. This will help contributors in ensuring that their changes are backward-compatible with the stable release branch, reducing potential regressions.
[ ] Stable Release Branch: Starting from NixOS 24.11, we will introduce a stable release branch that will only receive features that are backward-compatible. This change aims to prevent issues like #306, #373, and #259 from recurring in the stable branch.
Codebase
with lib;
at the Beginning of Files: Avoid usingwith lib;
at the start of files to improve code clarity, especially in environments lacking tree-sitter or a robust LSP. Removing these statements will make scoping clearer and align with the best practices outlined in Nix documentation.New features
plasma-manager
CLI Interface: Develop a unified CLI tool namedplasma-manager
to unify our scripts likerc2nix
andwrite-config
, as mentioned in #337. This tool will serve as a single entry point for current and future scripts (e.g., kxmlgui), promoting a shared library for our scripts. The CLI will be installed by default when enabling plasma-manager, allowing users to execute commands likeplasma-manager rc2nix
.