Tracking Issue: Codebase Improvements

[HeitorAugustoLN]

Feedback and suggestions on these proposed changes are welcome :)

General

• 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 7fb80fe, and will streamline versioning efforts (see Versioning + FlakeHub #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 Error " 'fromHexString' missing" when configuring touchpad #306, error: undefined variable 'plasmusic-toolbar' #373, and Application-title-bar, plasmusic undefined wuth Auto installing #259 from recurring in the stable branch.

Codebase

• Remove with lib; at the Beginning of Files: Avoid using with 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

• Implement plasma-manager CLI Interface: Develop a unified CLI tool named plasma-manager to unify our scripts like rc2nix and write-config, as mentioned in Make rc2nix stable #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 like plasma-manager rc2nix.

[magnouvean]

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 :)

[HeitorAugustoLN]

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! 😄

[SigmaSquadron]

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?

[HeitorAugustoLN]

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?

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.