JBoss Community Archive (Read Only)

RHQ 4.9

Source Control

RHQ Source Repository

The RHQ Project source is maintained in a Git repository.

GIT acccess

Anonymous:http://git.fedorahosted.org/git/?p=rhq/rhq.git

Committer:
ssh://git.fedorahosted.org/git/?p=rhq/rhq.git

Branch/Development Strategy

The branching strategy is summarized by the diagram below:

images/author/download/attachments/73139240/RHQSourceControl-2.png

Master

The 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:

  • must not break the build

  • should not break unit tests

  • should include new unit tests for any new enhancement

  • should satisfy all targeted runtime environments (jdk,database,os)

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 Releases

Community 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 Branch

The community final release will be generated from a release branch off of Master. Release branch is generated when the feature set for
the current version is complete. Release branch will then be used for feature hardening and, when stable, release generation.

Community Final Releases

Community 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 Releases

RHQ 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 Branches

No 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.

Feature Branches

It 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 Scenarios

Although 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. Squash

In 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.

Squash

In 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:

  • You should be confident that the single squashed commit will be final.

  • Create a local, short-lived branch for the work. Squash the work in that branch into a single commit.

  • You must destroy the branch generating the squashed commit after it is committed. It is not allowed to generate further commits from that branch.

Cherry Picking

In 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 Master

This will be the typical scenario, a feature, or bug fix, branch going into Master.

Feature Branch to Release

This 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 Master

Release 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 Branching

Tags will be generated in Master for:

  • Each community build

Branches will be generated off of Master for:

  • Feature branches

  • Bugfix branches

  • Release branches

Tags will be generated in Release for:

  • Each Community Final release

  • The GA product tag

Branches will be generated off of Release for:

  • Bugfix branches

  • Point release branches. Unlikely but if necessary Release could be branched to support a GA point release.

Example community beta release tags:

  • RHQ_3_0_0_B01

  • RHQ_3_0_0_B02

Example community final release tag:

  • RHQ_3_0_0

Example product release tag:

  • RHQ_3_0_0_GA

Example Release Artifacts:

  • rhq-enterprise-server-3.0.0.B01.zip

  • rhq-enterprise-server-3.0.0.zip

  • rhq-enterprise-server-3.0.0.GA.zip

Best link at the moment: Community Release Build Instructions

Branch Naming

Release Branch Naming

The Master branch will generate Release branches. The branch name format will be:

  • release-MasterMajor.MasterMinor.MasterPoint

Example Release Branches:

  • release-3.0.0

QA Impact

There will also be tagging and releases performed specifically for internal QA purposes. For those authorized, see Here.

Community contribution

TBD

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 08:21:07 UTC, last content change 2013-09-18 19:40:37 UTC.