Code Version Management
Code Repository
Freesynd uses now GIT as a versionning tool (moving from SVN).
Originally, only one SVN repository as use to store all assets source code.
With GIT, a separation has been made into different repositories :
* Code FreeSynd : This repository contains the code of the Freesynd game and the editor.
* Code Web : This repository contains the code for the Freesynd Website
See [Git_CheatSheet] for common Git actions.
Versioning
We are using Semantic Versioning.
Our major version is currently 0 until we publish what we will consider to be the target version.
Minor version is increased when a new set of features are released.
Patch is increased when only bug fixes are delivered.
Branching strategy
The branching strategy used for the project is inspired from this article.
Requirements
- As an open source project with no full time developers, it's hard to spend time on the repository management. So a workflow like the Git Workflow may be to difficult to manage. So we have to keep things simple.
- There are no automated test suites to validate every commit. We only do manual testing to validate a release (hope this can change).
- Sorceforge does not provide merge request when cloning a repo.
- We don't maintain multiple releases in parallel. If a bug is observed in a release, it will be fixed in the next major release. Even we keep the possibility to package a release with a fix for blocking problem.
Branching guidelines
- The main branch is used is used to develop new features and refactor. Each feature or refactor is developed in a branch from the main and then merge back.
- When a release is considered, a release branch is made from the main with all the features embedded in it. This feature branch will not contain new features, only bug fixes. Those bug fixes will be ported to the main branch.
- Once the release branch is stable, a tag is made and the code is package publicly.
- If a bug needs to be fixed in this release, it is fixed on this branch and a tag is made with the patch version increased.
- When we decide to start a new major or minor version, a new release branch is made from the main.
- It may be possible to use feature toggling when a non mature feature is embedded in a release.
Branch naming
Here are some suggestions :
* feature/feature-name
* feature/feature-domain/feature-name
* bugfix/short-description
* bugfix/#issue
* release/Major.Minor
Tagging name
Tag name are based on the version of the application to release.