Merge window - Revision history

Karellen at 20:17, 7 December 2020

2020-12-07T20:17:04Z

← Older revision		Revision as of 20:17, 7 December 2020
Line 1:		Line 1:
	{{mininav~~\|[[Team Kodi]]{{l2~~\|[[Development]]}}}}		{{mininav\|[[Development]]}}


	<br />		<br />

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

	== Window version bump ==		== Window version bump ==

Karellen at 10:50, 20 July 2020

2020-07-20T10:50:00Z

← Older revision		Revision as of 10:50, 20 July 2020
Line 1:		Line 1:
	{{mininav\|[[Team Kodi]]{{l2\|[[Development]]}}~~\|[[:Category:Team Kodi specific notes]]<br /> ~~}}		{{mininav\|[[Team Kodi]]{{l2\|[[Development]]}}}}


Line 23:		Line 23:

	If you have a simple bug fix, you can slot it straight into master whenever you like (given that you're a team member). 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 simple bug fix, you can slot it straight into master whenever you like (given that you're a team member). 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.

	~~See: [[Development advisors]]~~


	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 20th 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 20th of the month. If you miss the window, too bad - wait for the next alpha month.		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 20th 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 20th of the month. If you miss the window, too bad - wait for the next alpha month.
Line 49:		Line 46:
	# Once signed of the PR can be assigned to the next alpha merge window milestone.		# Once signed of the PR can be assigned to the next alpha merge window milestone.
	# If review takes to long don't hesitate to bug who must do the sign off.		# If review takes to long don't hesitate to bug who must do the sign off.
	# Make sure it compiles okay in [[Jenkins]]		# Make sure it compiles okay in Jenkins
	# If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go		# If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go

	~~== See also ==~~
	* [[Kodi development]]
	* [[Git Usage]]
	* [[HOW-TO:Submit a patch]]

	[[Category:Development]]		[[Category:Development]]
	~~[[Category:Team Kodi specific notes]]~~

Razze: Added steps for building and building with jenkins

2015-10-23T13:40:08Z

Added steps for building and building with jenkins

← Older revision		Revision as of 13:40, 23 October 2015
Line 42:		Line 42:

	=== Steps ===		=== Steps ===
			# Make sure your branch compiles fine for you
	# Do a PR for features or things that need some reviewing or you are unsure of		# Do a PR for features or things that need some reviewing or you are unsure of
	# Assign the appropriate label(s) that are available		# Assign the appropriate label(s) that are available
Line 48:		Line 49:
	# Once signed of the PR can be assigned to the next alpha merge window milestone.		# Once signed of the PR can be assigned to the next alpha merge window milestone.
	# If review takes to long don't hesitate to bug who must do the sign off.		# If review takes to long don't hesitate to bug who must do the sign off.
			# Make sure it compiles okay in [[Jenkins]]
	# If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go		# If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go

Razze: /* Window version bump */

2015-10-23T12:05:46Z

Window version bump

← Older revision		Revision as of 12:05, 23 October 2015
Line 11:		Line 11:
	in the next merge window should be a bump to 15.0-alpha2, 15.0-alpha3 and so on.		in the next merge window should be a bump to 15.0-alpha2, 15.0-alpha3 and so on.
	This bump should be done on the first day of every month.		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.		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.

Razze: /* Procedure */

2015-10-23T12:04:59Z

Procedure

← Older revision		Revision as of 12:04, 23 October 2015
Line 24:		Line 24:

	See: [[Development advisors]]		See: [[Development advisors]]


	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 20th 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 20th of the month. If you miss the window, too bad - wait for the next alpha month.		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 20th 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 20th of the month. If you miss the window, too bad - wait for the next alpha 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.		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'''		'''Github milestone'''

Razze: Updated to last changes

2015-10-23T12:04:15Z

Updated to last changes

Razze: Change from XBMC to Kodi

2015-10-23T09:34:03Z

Change from XBMC to Kodi

← Older revision		Revision as of 09:34, 23 October 2015
Line 1:		Line 1:
	{{mininav\|[[Team ~~XBMC~~]]{{l2\|[[Development]]}}\|[[:Category:Team ~~XBMC~~ specific notes]]<br /> }}		{{mininav\|[[Team Kodi]]{{l2\|[[Development]]}}\|[[:Category:Team Kodi specific notes]]<br /> }}


	<br />		<br />

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

	== Window version bump ==		== Window version bump ==
Line 14:		Line 14:
	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.		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.		kodi.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.		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 ==		== 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.		In order to minimise the periods where features are added to Kodi, and to encourage review of features prior to addition, the Kodi 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 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.
Line 46:		Line 46:

	== See also ==		== See also ==
	* [[~~XBMC~~ development]]		* [[Kodi development]]
	* [[Git Usage]]		* [[Git Usage]]
	* [[HOW-TO:Submit a patch]]		* [[HOW-TO:Submit a patch]]

NedBot: Robot: Changing Category:Team XBMC specific notes to Category:Team Kodi specific notes; cosmetic changes

2014-11-17T22:32:06Z

Robot: Changing Category:Team XBMC specific notes to Category:Team Kodi specific notes; cosmetic changes

← Older revision		Revision as of 22:32, 17 November 2014
Line 1:		Line 1:
	{{mininav\|[[Team XBMC]]{{l2\|[[Development]]}}\|[[:Category:Team XBMC specific notes]]<br/> }}		{{mininav\|[[Team XBMC]]{{l2\|[[Development]]}}\|[[:Category:Team XBMC specific notes]]<br /> }}


Line 51:		Line 51:

	[[Category:Development]]		[[Category:Development]]
	[[Category:Team ~~XBMC~~ specific notes]]		[[Category:Team Kodi specific notes]]

Martijn at 08:07, 2 September 2013

2013-09-02T08:07:50Z

← Older revision		Revision as of 08:07, 2 September 2013
Line 1:		Line 1:
	{{mininav\|[[Team XBMC]]{{l2\|[[Development]]}}\|[[:Category:Team XBMC specific notes]]<br/> }}}}		{{mininav\|[[Team XBMC]]{{l2\|[[Development]]}}\|[[:Category:Team XBMC specific notes]]<br/> }}

Martijn at 08:07, 2 September 2013

2013-09-02T08:07:26Z

← Older revision		Revision as of 08:07, 2 September 2013
Line 1:		Line 1:
			{{mininav\|[[Team XBMC]]{{l2\|[[Development]]}}\|[[:Category:Team XBMC specific notes]]<br/> }}}}


	<br />		<br />

← Older revision		Revision as of 12:04, 23 October 2015
Line 9:		Line 9:

	Each merge window will be defined as an alpha release. Thus, the first commit		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.		in the next merge window should be a bump to 15.0-alpha2, 15.0-alpha3 and so on.
	This bump should be done on the first day of every month.		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.		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.

	kodi.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.		kodi.addon will be 14.9.1 for the first alpha in the 15.0 release series, 14.9.2 for the second, etc. This way final release will be 15.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.		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 ==		== Procedure ==
	In order to minimise the periods where features are added to Kodi, and to encourage review of features prior to addition, the Kodi 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.		In order to minimise the periods where features are added to Kodi and to encourage review of features prior to addition, the Kodi 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 only.

	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 simple bug fix, you can slot it straight into master whenever you like (given that you're a team member). 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.		See: [[Development advisors]]

			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 20th 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 20th of the month. If you miss the window, too bad - wait for the next alpha 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.		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.
Line 29:		Line 31:
	'''Github milestone'''		'''Github milestone'''

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

	Assigning a PR to a milestone will mean it has been accepted and signed of by the devs responsible.		Assigning a PR to a milestone will mean it has been accepted and signed of by the devs responsible.
Line 41:		Line 43:
	# Assign a reviewer that will sign of your PR (maybe there should be multiple) and ping him about this		# Assign a reviewer that will sign of your PR (maybe there should be multiple) and ping him about this
	#* '''''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.''		#* '''''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.''
	# Once signed of the PR can be assigned to the next merge window milestone.		# Once signed of the PR can be assigned to the next alpha merge window milestone.
	# If review takes to long don't hesitate to bug who must do the sign off.		# If review takes to long don't hesitate to bug who must do the sign off.
	# If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go		# If merge window is open feel free to merge because it has been assigned to the milestone and is deemed ready to go