Define and adopt a GitFlow strategy for EOReader

[ArthurVincentCS]

To improve the structure, clarity, and scalability of EOReader's development workflow, it would be valuable to consider adopting a gitflow branching model.

Why

EOReader is becoming increasingly collaborative, and new contributions (such as the addition of sensors or improvements to the API) are more frequent. A structured branching strategy can help:

• Separate stable production code from ongoing feature development
• Encourage cleaner integration of external contributions
• Clarify the release process (especially for tagging, changelogs, and hotfixes)
• Reduce risks of regressions in the main branch

Suggested GitFlow model

• main: always stable, tagged releases only
• develop: integration branch for ongoing work
• feature/<name>: for individual features or improvements
• hotfix/<name>: for urgent fixes made on main

Proposal

• Document this workflow in CONTRIBUTING.md or a dedicated DEVELOPMENT.md
• Enforce protected branches on main and develop
• Encourage contributors to open PRs from feature branches into develop
• Use main only for release tags and production-level code

Summary

References

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

[remi-braun]

I totally agree with this. This should be done if the PR traffic increases. 👍