2014-01-13, 04:05 PM
MyBB Development Workflow
MyBB follows an adjusted Gitflow workflow for development of its products, including 1.6, 1.8, 2.0 and Merge System.
This workflow uses a central repository split into two branches; master and feature. This document demonstrates some of the interactions developers will come across when working with MyBB and provide processes they should follow.
Fixing a Bug
Each bug should be fixed via a dedicated branch forked directly off master. This branch should be named with the issue number and fix- prefix (fix-[issue_number]; e.g. fix-1234).
![[Image: fix.png]](https://camo.mybb.com/c9475dd6d2c7575b0a679448f7e6cb6a261b3f27/687474703a2f2f78656b6b6f2e636f2e756b2f7075626c69632f6d7962622f6669782e706e67)
Process
Within your forked version of the mybb repository, create a branch off master and name it fix-[issue_number]. You can make as many commits as necessary (see fix-1235) to resolve the issue before merging the changes back into your master and feature branches.
When you have confirmed that your changes are complete make a pull request to merge your changes into the mybb repository. A member of the MyBB Team (or any contributor) can review your work, provide feedback or discuss changes before the pull request is completed.
Please make sure that your work follows the MyBB Development Standards and you have checked for any potential security issues. fix branches should also be merged in feature wherever possible.
This process keeps a complete history of your work for easy reference.
Adding a Feature
Before adding a feature into MyBB please consider discussing the changes you’re making on the MyBB forums or by adding a new GitHub Issue. This will allow other users to find out more about your suggestion and be involved in its introduction.
A “feature” is a change that affects core functionality not related to fixing a reported bug. Features may vary from small performance changes, or rewriting parts of code, to adding completely new sections.
Process for MyBB 1.6
No new features should be added to MyBB 1.6.
Process for MyBB 1.8
![[Image: feature-1.8.png]](https://camo.mybb.com/53365987a7f5a87625d1f7894a67317d6e534455/687474703a2f2f78656b6b6f2e636f2e756b2f7075626c69632f6d7962622f666561747572652d312e382e706e67)
Within your forked version of the mybb repository, create a branch off feature and name it feature-[issue_number] (e.g. feature-1235).
The issue number should correspond to the ticket number on GitHub Issues for your feature. If one does not exist please create one. This will allow other users to contribute and discuss your feature and changes.
Once your changes are completed make a pull request to merge your changes back into the mybb repository. A member of the MyBB Team (or any contributor) can review your work, provide feedback or discuss changes before the pull request is completed.
Special attention should be made to potential security issues for new features. Please remember to follow the MyBB Development Standards.
Releases
The MyBB Team will ensure that the code found in the master branch is stable and ready for release. Users of MyBB, however, should only use official releases in the series (available to download from MyBB.com) and not use code from the repository in a live environment.
Code from the repository, minus tagged releases, should only be used for development purposes. Only official releases are supported in the Support Forums at MyBB.com.
![[Image: release.png]](https://camo.mybb.com/1d9a33c14ce8bc1cf0715825667440455322e3c6/687474703a2f2f78656b6b6f2e636f2e756b2f7075626c69632f6d7962622f72656c656173652e706e67)
Process
Every two months, at the start of the month, a new branch called release is created off master to prep for official release. At this point no pull requests or changes should be made to the master branch.
This release cycle should continue regardless of the number of changes. This ensures users of MyBB get a regular update whether there is 1 or 100 bugs fixed. However the MyBB Development Team may defer, delay or bring forward releases (in cases of no bugs fixed or a security release, for example).
Security releases will be unaffected by the release cycle and will be made available when appropriate patches are made to vulnerabilities.
Changes in the release branch will include core and language versions. Translators, plugin and theme developers should watch out for this process and prepare their work accordingly.
![[Image: release-fix.png]](https://camo.mybb.com/2ed8ae2886d955b3acd2623ccaff0e1b0cc0d54f/687474703a2f2f78656b6b6f2e636f2e756b2f7075626c69632f6d7962622f72656c656173652d6669782e706e67)
The release branch also needs tested and verified by the MyBB SQA Team for quality purposes. If further changes are needed for the release these changes should be made via the release branch. Only when the MyBB SQA Team has passed verification should release be merged into master and tagged as a release.
Summary
![[Image: summary.png]](https://camo.mybb.com/d3be43cda0ef6e05852809e3045598d8ccfa3e41/687474703a2f2f78656b6b6f2e636f2e756b2f7075626c69632f6d7962622f73756d6d6172792e706e67)
This workflow is focused on making sure bugs and features are kept out of the master branch, which should always be ready for release, while making it quick and simple for contributors to work on MyBB.
If there are any questions or concerns regarding the MyBB development workflow, or you want more information, please use the MyBB.com forum.
MyBB follows an adjusted Gitflow workflow for development of its products, including 1.6, 1.8, 2.0 and Merge System.
This workflow uses a central repository split into two branches; master and feature. This document demonstrates some of the interactions developers will come across when working with MyBB and provide processes they should follow.
Fixing a Bug
Each bug should be fixed via a dedicated branch forked directly off master. This branch should be named with the issue number and fix- prefix (fix-[issue_number]; e.g. fix-1234).
Process
Within your forked version of the mybb repository, create a branch off master and name it fix-[issue_number]. You can make as many commits as necessary (see fix-1235) to resolve the issue before merging the changes back into your master and feature branches.
When you have confirmed that your changes are complete make a pull request to merge your changes into the mybb repository. A member of the MyBB Team (or any contributor) can review your work, provide feedback or discuss changes before the pull request is completed.
Please make sure that your work follows the MyBB Development Standards and you have checked for any potential security issues. fix branches should also be merged in feature wherever possible.
This process keeps a complete history of your work for easy reference.
Adding a Feature
Before adding a feature into MyBB please consider discussing the changes you’re making on the MyBB forums or by adding a new GitHub Issue. This will allow other users to find out more about your suggestion and be involved in its introduction.
A “feature” is a change that affects core functionality not related to fixing a reported bug. Features may vary from small performance changes, or rewriting parts of code, to adding completely new sections.
Process for MyBB 1.6
No new features should be added to MyBB 1.6.
Process for MyBB 1.8
Within your forked version of the mybb repository, create a branch off feature and name it feature-[issue_number] (e.g. feature-1235).
The issue number should correspond to the ticket number on GitHub Issues for your feature. If one does not exist please create one. This will allow other users to contribute and discuss your feature and changes.
Once your changes are completed make a pull request to merge your changes back into the mybb repository. A member of the MyBB Team (or any contributor) can review your work, provide feedback or discuss changes before the pull request is completed.
Special attention should be made to potential security issues for new features. Please remember to follow the MyBB Development Standards.
Releases
The MyBB Team will ensure that the code found in the master branch is stable and ready for release. Users of MyBB, however, should only use official releases in the series (available to download from MyBB.com) and not use code from the repository in a live environment.
Code from the repository, minus tagged releases, should only be used for development purposes. Only official releases are supported in the Support Forums at MyBB.com.
Process
Every two months, at the start of the month, a new branch called release is created off master to prep for official release. At this point no pull requests or changes should be made to the master branch.
This release cycle should continue regardless of the number of changes. This ensures users of MyBB get a regular update whether there is 1 or 100 bugs fixed. However the MyBB Development Team may defer, delay or bring forward releases (in cases of no bugs fixed or a security release, for example).
Security releases will be unaffected by the release cycle and will be made available when appropriate patches are made to vulnerabilities.
Changes in the release branch will include core and language versions. Translators, plugin and theme developers should watch out for this process and prepare their work accordingly.
The release branch also needs tested and verified by the MyBB SQA Team for quality purposes. If further changes are needed for the release these changes should be made via the release branch. Only when the MyBB SQA Team has passed verification should release be merged into master and tagged as a release.
Summary
This workflow is focused on making sure bugs and features are kept out of the master branch, which should always be ready for release, while making it quick and simple for contributors to work on MyBB.
If there are any questions or concerns regarding the MyBB development workflow, or you want more information, please use the MyBB.com forum.