Merge window

This page describes the "merge window" procedure used by Team XBMC to merge pull requests into the master git branch.

Window version bump
Each merge window will be defined as an alpha release. Thus, the first commit in the next merge window should be a bump to 12.0-alpha2, 12.0-alpha3 and so on. This bump should be done on the first day of every month.

For internal versioning that cannot be handled with strings, we use currentvers + .9 instead, so that versions are always incrementing. It's not nice to mix, but since they're for dev use only, confusion should be minimal.

xbmc.addon will be 11.9.1 for the first alpha in the 12.0 release series, 11.9.2 for the second, etc. This way final release will be 12.0.0 as expected. configure.in is handled the same way.

In addition Android needs to have an addition bump in "android:versionCode". This is an integer number that should be raised on each release.

Procedure
In order to minimise the periods where features are added to XBMC, and to encourage review of features prior to addition, the XBMC team operates a merge window policy. New features may only be merged from a pull request (PR) during the merge window. The rest of the time is left for bug fixing.

If you have a simple bug fix, you can slot it straight into master whenever you like. If it is a non-trivial bugfix, then it's probably best to do a pull request, asking for the specific folk who should review prior to going in.

If you have a new feature addition, then it needs to go through a pull request. Currently the merge windows are the 1st to the 10th of the month. Thus, if you have a new feature, you first do a pull request, and then solicit review. Assuming review brings up no issues, you can assign it to the merge window (using github issues) and pull it in during the 1st to the 10th of the month. If you miss the window, too bad - wait for the next month.

If you do a pull request and get little feedback, then make sure you specifically request the feedback from those that are most appropriate to review.

Github milestone

For each merge we will create a milestone on which PRs can be assigned. For February this will be "13.0-alpha1 February"

Assigning a PR to a milestone will mean it has been accepted and signed of by the devs responsible.

Steps

 * 1) Do a PR for features or things that need some reviewing or you are unsure of
 * 2) Assign the appropriate label(s) that are available
 * 3) Assign a reviewer that will sign of your PR (maybe there should be multiple) and ping him about this
 * 4) * Note: GitHub only allows one person to be assigned a PR, so if multiple sign offs are required, just put in one and ping/poke the others.
 * 5) Once signed of the PR can be assigned to the next merge window milestone.
 * 6) If review takes to long don't hesitate to bug who must do the sign off.
 * 7) If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go