Skip to content

Proposal to simplify branch strategy due to excessive branches #148

@LinuxBoy-96

Description

@LinuxBoy-96

This is not usually the type of issue I open, but there are simply too many branches in this project right now.

I believe that having 3 or 4 main branches would be enough and easier to manage, for example:

main: Stable release — Long-term support

beta: Minor tweaks and testing

alpha: Small feature additions and bug fixes

experimental: Major changes and refactoring

The idea is that each branch gets synced with the branch below it once it's stable enough.

I’m not trying to police the project, but I want to ensure that everyone contributing — from experienced developers to newcomers — clearly understands where to push their work, creating a logical and progressive flow of versions and commits.

Right now, I don’t know where to push anymore. Many branches are simultaneously ahead and behind main by dozens or even hundreds of commits. I can only imagine how chaotic merging all these branches will be, and I fear my own code might get lost or overwritten.
What features are in which branch right now? What is the workflow? I have no clue.

Additionally, on PR #146, before the merge, a commit was added modifying Cargo.toml by adding widestring under the internationalization section. This dependency only makes sense if the project supports Windows.

I suspect this unrelated commit was introduced because of confusion caused by the many branches.

Additionally, any changes to **documentation (e.g. README.md) should be submitted in a separate PR, ideally condensed into a minimal number of commits.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions