The main branch has our released code. Changes are only pushed to this branch in preparation for a release. This is the default landing point for the public when they come to our repository.
The develop branch has our "working" code. Pull requests by developers are supposed to be against this branch, and are accepted by project management if they meet our guidelines and have all tests passing.
Current and older released versions of the code are found in the "releases" (on the right side of the. GitHub page) or via tags in the commit history.
Work-in-progress by contributors is found in their own forks.
This design is understandable but problematic. By having our "main" branch be not our most up-to-date development version, we end up with contributors submitting pull requests against "main" that then need to be reconciled with "develop". Instead, we should adopt the organization system used by most other popular public repos (pandas, array, and even Python itself):
The develop branch goes away.
The main branch has our "working" code. Pull requests by developers are supposed to be against this branch, and are accepted by project management if they meet our guidelines and have all tests passing.
Current and older released versions of the code are found in the "releases" (on the right side of the. GitHub page) or via tags in the commit history. They can also be stored as branches, to allow us to add patches to them if needed, instead of having only a single update path (get on the latest version or get no bug fixes).
Work-in-progress by contributors is found in their own forks.
Currently, the project is organized like this:
mainbranch has our released code. Changes are only pushed to this branch in preparation for a release. This is the default landing point for the public when they come to our repository.developbranch has our "working" code. Pull requests by developers are supposed to be against this branch, and are accepted by project management if they meet our guidelines and have all tests passing.This design is understandable but problematic. By having our "main" branch be not our most up-to-date development version, we end up with contributors submitting pull requests against "main" that then need to be reconciled with "develop". Instead, we should adopt the organization system used by most other popular public repos (pandas, array, and even Python itself):
developbranch goes away.mainbranch has our "working" code. Pull requests by developers are supposed to be against this branch, and are accepted by project management if they meet our guidelines and have all tests passing.