How to manage branches and versions when developing on the PLFM and client GIT projects
Cases:
Back end work only
Develop on own branch. Merge with master and push to remote at will (after successful local build).
Additive change to API
Portal work only (no API change)
...
Our strategy is to give PLFM a master branch and also an API-stable branch. Developers changing the master branch are not responsible for immediately verifying that the changes work with clients (and may even purposely 'break' the current APIs). However, changes to this branch are not immediately available to the clients. Workers changing the API-stable branch are responsible for testing (perhaps after making corresponding changes to) the clients and making sure they work.
1) If you're working on PLFM and the changes *don't* need to be used immediately by clients, then you may work off of the 'master' branch. Pull from the remote master, create a branch for your work, code and test, then merge back into master and push to github.
2) If you are just working on a client then you may work off the 'master' branch of the client's project, following the pattern described above. The client will depend on a particular branch of PLFM (not the master branch) having a stable API.
3) If you are making changes to PLFM's API and also are changing a client to reflect these changes, then:
- pull from the client's master branch (creating a local branch for development)
- pull from the PLFM's stable branch, which will have a name like '0.13.1'.
- develop and test locally
- run pomVersioner.py to increment version, e.g. from 0.13.1.1 to 0.13.1.2
to incorporate PLFM master with the API-stable branch
Say the latest API-stable branch is 0.13.7.
1) git checkout -b 0.13.8
2) git push origin 0.14.0
3) edit pomVersioner.py so 'newVersion' is 0.14.0; run 'python pomVersioner.py'