I would like to build a custom version of QGroundControl based on the latest stable release (Stable_V4.0). I am looking for recommendations on how to setup my Git flows which will allow me to customize QGroundControl while still retaining the ability to pull from (e.g. update to latest stable V4, upgrade to new stable V5, cherry pick from Master, etc) and contribute back to the upstream repository, and not work against (or perhaps work with) the existing git flow.
I intend to use a similar flow to QGroundControl; master branch used for development, feature branches off master, and stable branches off master when releasing.
I assume I should create a new development branch to avoid conflicts with the existing development branch ‘master’; e.g. a branch named ‘develop’. This new development branch would then branch from tag v4.0.05 (or should it branch from the HEAD of Stable_V4.0?)
My feature branches and release branches (i.e. stable branches) would then branch off ‘develop’.
Or should me ‘develop’ branch off the point where ‘Stable_V4.0’ branched off ‘master’; i.e. commit 3cb4f12. I would then merge ‘Stable_V4.0’ into my develop.
Or is there another way this is typically done?
Thanks in advance.
Matt.
Give me some time to write up a dev document for how to do this and add it to the docs. Lots of folks are working through the same thing. If you don’t hear back from me in a couple days, ping me again.
Brilliant! I look forward to it.
If you want to follow along on the correctness of these docs: https://github.com/mavlink/qgc-dev-guide/pull/87
1 Like
Thanks for the GitBranching write ups. Very helpful.
I’m still a little unclear how I layer on top of the QGC git strategy.
You write ups seem to assume I would want to develop from the latest daily build. Where I only ever want to develop from the latest stable build.
This is what I am trying to do:
- I would like to create a custom version of QGC based on the latest stable release Stable_V4.0.
- I understand that most of my modifications will be contained with the custom folder, but I am assuming there will be changes to core QGC outside of the custom folder. I am assuming I’m working in the same repository; perhaps I should be creating a submodule in the custom folder?
- I would like to layer my Git strategy on top of the QGC strategy. This is my understanding of what this would mean:
3.1 I would create a QGC repository which points to the upstream repository (https://github.com/mavlink/qgroundcontrol) and my own remote repository.
3.2 I would develop on my local master branch (using feature branches) and push to remote/master.
3.3 I would on a regular basis do an upstream merge by pulling upstream/master. I practice, I would do this rarely; I understand that this would make the merge very difficult.
3.4 I can create pull requests on upstream by creating a feature branch off my local master, in order to contribute back to QGC. I assume good candidates for this would be changes outside of the custom folder.
3.5 I would have a local Stable_V4.0, but I would not commit to this branch. Instead I would create a local MyStable_V1.0 which would branch off of Stable_V4.0 when I’m ready to release (i.e. as late as possible) my customization; e.g. in 12 months time.
3.6 I do not develop on MyStable_V1.0, I only apply patches. All development is on my local master.
3.7 I do my custom changes to local master and pull master into MyStable_V1.0 when I’m ready to create this release. I can also pull patches from Stable_V4.0, but it would be unlikely Stable_V4.0 would receive any patches during my release cycle.
Where my confusion lies:
- For now I would like to use only Stable_V4.0 commits, and not any of the commits which have since been added to upstream/master.
-
It looks like the latest Stable_V4.0 (v4.0.5, or even HEAD) have not yet been merged back into master. I assume it will be in the future?
- So I assume what I need to do is setup my master to point to where branch Stable_V4.0 was created (hash 3cb4f124). Then pull Stable_V4.0 (tag v4.0.5 or HEAD?) into my master. Then I can continue to work on master with the Stable_V4.0 patches.
- After doing #3, I would not pull from upstream/master for the foreseeable future. As I want to work from Stable_V4.0, not the latest daily build. At least until I can comfortable with QGC, and probably not until after my first release.
So my question is, how do I work from master such that it is current as of Stable_V4.0, and not include anything newer?
Or is what I’m describing what you are calling an ‘Out Of Band’ release?
If so, I understand that I would create a feature branch off of Stable_V4.0. This feature branch would in effect become my development branch (i.e. equivalent to the QGC master branch) and I would never commit to the master branch.
So for example, I would branch off Stable_V4.0 and create branch ‘develop’. I would create feature branches off ‘develop’. And when I am ready to release, I would create Stable branches off of ‘develop’.
I assume if I wish to contribute back to master, I would switch to master, create a feature branch and raise a PR, then cherry pick the changes back to ‘develop’ if the PR is accepted.
I hope what I’m asking is clear.
@px4_qgc_developer I’ve moved your questions to the pull request I referenced above. You we continue the discussion there instead?
