RHQ Source RepositoryThe RHQ Project source is maintained in a Git repository. GIT acccessAnonymous: http://git.fedorahosted.org/git/?p=rhq/rhq.git Committer: Branch/Development StrategyThe branching strategy is summarized by the diagram below:
MasterThe Master branch is basically the community development branch for the project. It will include the latest stable features. A push to Master should be done only for completed features or fixes and only with the blessing of the RHQ project maintainers. It:
It is a goal of the overall source control process that Master never be blocked for commits (aka "frozen") for any substantial amount of time. Community Beta ReleasesCommunity beta releases will be generated regularly from Master, mainly date-based as opposed to feature-based. They will make available the latest features as binaries but will be the least qualified releases. These releases are targeted at the development community for early access feature evaluation and work. They will be versioned X.Y.Z_B01..B0N Release BranchThe community final release will be generated from a release branch off of Master. Release branch is generated when the feature set for Community Final ReleasesCommunity final releases will be generated at the end of each scheduled Major or Minor version. They will make available the features for that version as binaries and will be the most stable community releases. These releases are targeted for use by community members not requiring formal project support. No further community releases will be made from Release branch. They will be versioned X.Y.Z. It may also include features and fixes made to Master after the branch-point. Release branch is created at a time, typically, when Master includes as many features as are targeted for the release, and no more than that. Otherwise Release branch would need to remove or disable the feature. This is not desirable as it can generate excess build options and/or coding. Although rare, it may happen that a feature or fix will be migrated from Master, to Release branch. Simple changes can be cherry-pick from Master but for larger changes it is recommended that the fix or feature branch be formally merged into Release branch. No fix or feature may be applied to Release branch without explicit permission from the RHQ Lead. Product ReleasesRHQ is the primary upstream project for the JBoss Operations Network (JON) product. Following the community final release, the Release branch will be further hardened for use by JON. When satisfying the JON product needs, the release branch will be tagged. This tag will be used as the JON upstream version. Further work in Release branch would be for GA patch work. They will be tagged RHQ_X_Y_Z_GA. Feature BranchesNo feature work should be performed directly in a Master tracking branch. It is recommended that bug-fix work also be performed in its own branch. This provides maximum flexibility for making appropriate pushes to Master. Feature development can span multiple community releases, or potentially even multiple product releases. The same rules apply to feature or bug-fix work being done in Release branch. Sub-Feature BranchesIt is certainly within reason to have feature branches off of feature branches. These branches should typically be merged only into their parent feature branch. Merge ScenariosAlthough the goal is to minimize merges there are times when it is necessary. GIT provides powerful merge help, but care must be taken to ensure a merge does not regress the branch. Enlist help if you have any doubts whatsoever about the correctness of the merge. Call for review when it is complete. Merge vs. SquashIn general the RHQ team recommends GIT Merge over Git Squash. Time has shown us that merge has been more reliable and less error-prone than trying to squash commits and cherry-pick large features or bug-fixes. It is recommended that when feasible git Merge is used multiple times to merge a change into various target branches. The most typical scenario being a merge into Master and the current Release Branch. SquashIn limited scenarios a squash commit may make cherry picking a feature or fix a bit easier. But it can be problematic if the fix or feature is not completely, 100% done in that single squashed commit. If you insist on using a squashed commit the following should be true:
Cherry PickingIn general the RHQ team recommends GIT Merge as opposed to cherry picking. Cherry picking commits is useful but should be limited to simple, single commits. Feature Branch to MasterThis will be the typical scenario, a feature, or bug fix, branch going into Master. Feature Branch to ReleaseThis will be less common but certainly will occur. The feature or fix must first be applied to Master. It may then, if approved, be applied to Release branch. The recommendation is to use GIT Merge to merge from the change branch to Release branch. But, if simple, cherry picking the commit(s) from Master to Release is possible. Release to MasterRelease branch work should also be merged to Master. In short, there should be nothing in Product that could not also be in Master. This will much more likely be bug fixes rather than features, as the release branch will receive more intensive quality assurance, and feature addition in a release branch is unlikely. For a high priority fix that can not wait for the branch merge, the developer can decide whether it is best to perform a sub-branch merge, a cherry-pick, or to simply code the fix multiple times, once in a Product branch and once in a Master branch. Tagging and Other BranchingTags will be generated in Master for:
Branches will be generated off of Master for:
Tags will be generated in Release for:
Branches will be generated off of Release for:
Example community beta release tags:
Example community final release tag:
Example product release tag:
Example Release Artifacts:
Best link at the moment: Community Release Build Instructions Branch NamingRelease Branch NamingThe Master branch will generate Release branches. The branch name format will be:
Example Release Branches:
QA ImpactThere will also be tagging and releases performed specifically for internal QA purposes. For those authorized, see Here. Community contributionTBD |
