Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

How to manage branches and versions when developing on the PLFM and client GIT projects

 

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 AP(s).  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.

PLFM Branch ChoiceAdvantagesDisadvantages
masterMay 'break' client; need not verify client functionality.Changes are not immediately available to client developers.
API-stableChanges are immediately available to client developersDeveloper must ensure client functionality.

 

Workflow

(to edit diagram, go to https://docs.google.com/a/sagebase.org/drawings/d/1s2zCr57TOajuuMHnD8xMXWVIWmPDINNE-MTFSMlNx4U/edit)

 

Development Workflows

Local PLFM changes

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.

Local Client changes

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 the API-stable branch.

Changes to PLFM and Client

If you are making changes to PLFM's API and also are changing a client to reflect these changes, then:

(to edit this document, goto https://docs.google.com/a/sagebase.org/drawings/d/1X05G5t_8tzW8lQjroQQk3HH9aTHYyvFZfPMg1eckTuU/edit)

- 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.1

- push to 0.13.1.1

- push to the client's master branch

- on PLFM, git checkout master

- pull from remote

- merge the API-stable branch's changes

- resolve any conflict and get a clean build

- run the pomVersioner to increment the master's version, e.g. to 0.13.2-SNAPSHOT

- push to the PFLM master branch

 

Incorporating PLFM master with the API-stable branch

(to edit, go to : https://docs.google.com/a/sagebase.org/drawings/d/1WUtUpzq1vtbv9nd1o3S3Dq_cUbLoDczDFqZBv3Pl3PI/edit)

 

Pull from PLFM master

- on master, 'git checkout -b 0.13.2' to create the new branch

in the client project, pull from master, changing the version to be the version of the local PLFM snapshot (0.13.2-SNAPSHOT)

work to make client and PLFM work together

in PLFM branch, change version to 0.13.2.1 and push

in client master, change version to 0.13.2.1 and push

in PLFM master, merge the branch, change version to 0.13.3-SNAPSHOT and push to remote

 

 

 

 

 

  • No labels