I am writing a simple framework that I want to open source just for experience (and fun!). However, it has some cool ideas that could make it grow to a larger project and I want to be ready if that ever happens. I highly doubt that that will happen, but I want to use this as a learning experience on how to properly run an open source project.
I want to dive right into the development. I'm not too worried about the actual code since it should be mostly simple. However, I'm not that experienced with Github. I mean, I know all the basics and such, but I don't really know how to use all of the tools to my advantage.
How should I manage a workflow to best accommodate developers? I'm going to try to encourage the "standard" procedure:
- Fork the repository
- Clone the repository to your Git client
- Make a new branch for the work
- Do the actual work
- Commit your work (if multiple commits, rebase them to create one commit for easy history on the main repo)
- Submit a pull request with that one commit
Then, obviously, I will choose if I want to pull it or not. Here's where I get stuck. How should I manage my branches?
I drafted up this design:
masterbranch is for stable releases. Individual pull requests are only sent to the master branch if it's a critical bug and needs an individual release ASAP.
betabranch is for the code for the next stable release. Bug fixes will be pulled to this branch.
alphabranch is where the feature requests are added.
When a commit (not a pull request) is added to either the master or beta branch, the changes are "cascading" (i.e. a pull request is automatically created so that a commit to master will also be on beta and alpha; a commit on beta will be on alpha). I would do this with a simple script. Albeit it'd be somewhat ghetto, but it'd be automatic.
For a standard release, the beta would be merged into the master and then the alpha into the beta branch.
The reason for this is the feature requests aren't put into the next version so they're stable enough to be in the stable release.
Is this dumb? A consolidated "dev" branch would be the easiest to manage, but I'm afraid that some bugs would still get through. I guess I'd have to stop accepting feature additions a little bit before I release a new version.
EDIT: This question is extremely similar to my question: Is there an established or defined best practice for source control branching between development and production builds?. However, I'm looking at my proposed method vs. just not handling pull requests before a new release. Also, this is about open source software (so it might be harder to train new people on the system for this project).