-
Notifications
You must be signed in to change notification settings - Fork 25
CKAN GIT Process
danmihaila edited this page Dec 23, 2014
·
10 revisions
As it was suggested by several persons, we can base our process on The GIT Workflow
Mapping of current branches to workflow names
- dev = Develop
- staging = Release
- prod = Master
Versions will be tagged on the master branch. Only released versions will be deployed on the production server. Version numbers will be of the form A.B.C ( no more than 3 levels )
- A - Huge changes / feature affecting the structure, functionality or UI of most of the project
- B - New features added
- C - bug-fixing
- change version number in version.py
- stag branch will have version(tag) like : v0.5.12stag
- prod branch will have a version(tag) like: v0.5.12
- change pom.xml to have the value: 0.5.12
- dev branch will have a version(tag) like v.0.5.12
Any new change should be implemented in a new branch. The new branch should fork from:
- always dev ( one EXCEPTION below )
- prod in case an urgent hotfix is needed on a released version. After the fix is committed the new branch can be merged directly (through a pull request) in prod. Still the branch needs to also be merged into dev
dev will be the branch that will "push" the project forward; it will have the entire history of the project. Everything needs to (eventually) end up in dev
(enter your comments here and let the team know about it on the team chat)