How best to make our branching/pipeline work in order to help community development if necessary.
Scenario : We have a requirement wherein we have Bahmni 0.91 deployed already.We also have connect installed. As well one custom module deployed.
We are expecting some connect changes to be made to resolve certain issues at deployment. We are trying to come up with a branching/pipeline strategy to make sure that we can make sure that we could have it work on 0.91 for the existing setup as well as have it easier to merge back changes.
Components expected to have changes,
Now for us a priority is to setup our pipeline to build a Bahmni connect 0.91 deployable(s).
Following are the approaches we are thinking of,
Fork all required repos in our own org and do the changes there. Setup pipeline to build from this.
This was we can make customary changes to scripts etc as and when required and come up with the deliverable artefact for our scenario. If parallel development on master is not going on then we can have it easy when merging back.
Trouble while merging back as if there are parallel changes going on in those repos our rebase and merge back activity can very quickly get tricky.
We base all our development off of master
Super easy to get changes back to community.
Since we are working with a 0.91 setup its difficult to manage this as for one the infra code has changed significantly in later version(s) ie. 0.92 and now current master . So we will have to maintain our specific forks for the infra code to make it work for existing deployment. Also on the code front we need to be sure that the code in master should work in 0.91.
We are now favouring the first approach as it would give us a better opportunity to fulfill our objectives first and assuming bahmni-connect is not going to see any new remarkable changes in the recent future foreseeable merging back any new fixes should not be hard. We just wanted to put this out to make sure if there are other thoughts around it.