-
Notifications
You must be signed in to change notification settings - Fork 19
EZCast release and branching strategies
FEATURE(S)
Each new change (features, bugfixes, refactors, ...) must be commited into a new branch dedicated to the feature. These branches must start from dev branch.
Once the feature is complete, it can be merged back to the dev branch.
DEV
Dev branch, new features must be merged this branch. This should be your usual working branch, with every new features in a new branch starting from here.
STAGING
Staging branch, when preparing a release, dev should be merged on staging to validate changes before merging on master.
MASTER
Production branch. Every changes here must be stable and ready to be applied on a production server.
If you need to apply quick fixes to production (master branch):
- Commit the fix as a new feature on the dev branch.
- Switch back to master branch
- Cherry-pick the fix commit to master. In some cases, you may have to resolve conflicts by hand.
EZcast use the classic semantic versioning in the format :
MAJOR.MINOR.PATCH
- Major version is currently 1 and is not used for now.
- Minor version introduces new features, important refactors, or config/database changes.
- Patch version introduces small fixes or refactors only.
Each new version is followed by a release on the GitHub system, with a changelog explaining the changes. A new release should be done with every changes on the master branch.
Database version is stored in the database. The php code also knows which database versions it's supposed to be working with and will issue a warning upon connection on EZadmin if the versions missmatch.
Every databases changes should be stored in a script in the sql_updates folder at the root of the repository. Each patch is targeting specific database versions and will update the database structure and versions to a newer one.
(more details on the format are yet to define)