Development Team/Release - Revision history

Quozl: /* Fructose (base activity) modules */

2018-01-16T23:51:11Z

Fructose (base activity) modules

← Older revision		Revision as of 19:51, 16 January 2018
Line 58:		Line 58:
	===<abbr title="Fructose, the base set of demonstration activities">Fructose</abbr> (base activity) modules===		===<abbr title="Fructose, the base set of demonstration activities">Fructose</abbr> (base activity) modules===
	* Check out the branch of the project repository,		* Check out the branch of the project repository,
			* Increment the version number in the activity/activity.info metadata file,
			* Update any NEWS file with a list of changes, intended for a teacher or integrator,
	* Make the source tarball and bundle, which for most activities is done by {{Code\|bundlebuilder}} via {{Code\|setup.py}} and will place the result in the {{Code\|dist/}} directory:		* Make the source tarball and bundle, which for most activities is done by {{Code\|bundlebuilder}} via {{Code\|setup.py}} and will place the result in the {{Code\|dist/}} directory:
	python setup.py dist_source		python setup.py dist_source
Line 72:		Line 74:
	* Push the release tag to the project repository,		* Push the release tag to the project repository,
	git push --tags		git push --tags
	* Upload the bundle to activities.sugarlabs.org, with a high level, ~~user~~ oriented list of changes, which will cause a release mail to be sent to sugar-devel@lists.sugarlabs.org.		* Upload the bundle to activities.sugarlabs.org, with a high level, learner oriented list of changes, which will cause a release mail to be sent to sugar-devel@lists.sugarlabs.org.

	== Sugar release cycle==		== Sugar release cycle==

Quozl at 20:44, 2 November 2017

2017-11-02T20:44:12Z

← Older revision		Revision as of 16:44, 2 November 2017
Line 53:		Line 53:
	* Announce by mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and a high level, user oriented list of changes.		* Announce by mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and a high level, user oriented list of changes.
	* When the {{Code\|sugar}} module is released, update the Activity Library default stable release; the variable {{Code\|SITE_SUGAR_STABLE}} in site/app/config/config.php then check on [https://activities.sugarlabs.org activities.sugarlabs.org] with a browser other than Browse that an activity compatible with the release is listed.		* When the {{Code\|sugar}} module is released, update the Activity Library default stable release; the variable {{Code\|SITE_SUGAR_STABLE}} in site/app/config/config.php then check on [https://activities.sugarlabs.org activities.sugarlabs.org] with a browser other than Browse that an activity compatible with the release is listed.
			* One week later, check that the corresponding packages have been updated, and if not contact the downstream packager.
	{{Anchor\|Fructose}}		{{Anchor\|Fructose}}

Quozl: /* Automation */

2017-11-02T20:20:50Z

Automation

← Older revision		Revision as of 16:20, 2 November 2017
Line 151:		Line 151:

	Each commit or set of commit should have a ticket associated. The ticket number should be always mentioned in the git log and is used to automatically build the list of module changes for the releases.		Each commit or set of commit should have a ticket associated. The ticket number should be always mentioned in the git log and is used to automatically build the list of module changes for the releases.

	~~== Automation ==~~

	TBD Many of the steps described in this document can be easily automated for maintainers which are using the Sugar Labs infrastructure and for the release team. Though as a first pass we want to get the workflow right, even if it involves more manual step than strictly required.

	==Related pages==		==Related pages==

Quozl: remove sugar-tools release script, as it has not been maintained, and was not used for the 0.111 and 0.112 release, a new maintainer for sugar-tools is welcome

2017-11-02T20:18:00Z

remove sugar-tools release script, as it has not been maintained, and was not used for the 0.111 and 0.112 release, a new maintainer for sugar-tools is welcome

@@ Line 72: / Line 72: @@
   git push --tags
 * Upload the bundle to activities.sugarlabs.org, with a high level, user oriented list of changes, which will cause a release mail to be sent to sugar-devel@lists.sugarlabs.org.
 == Sugar release cycle==

Quozl: /* Glucose (base) modules */

2017-09-14T21:14:26Z

Glucose (base) modules

← Older revision		Revision as of 17:14, 14 September 2017
Line 51:		Line 51:
	* Push the release tag to the project repository,		* Push the release tag to the project repository,
	git push --tags		git push --tags
	* Announce by mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user oriented list of changes.		* Announce by mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and a high level, user oriented list of changes.
	* When the {{Code\|sugar}} module is released, update the Activity Library default stable release; the variable {{Code\|SITE_SUGAR_STABLE}} in site/app/config/config.php then check on [https://activities.sugarlabs.org activities.sugarlabs.org] with a browser other than Browse that an activity compatible with the release is listed.		* When the {{Code\|sugar}} module is released, update the Activity Library default stable release; the variable {{Code\|SITE_SUGAR_STABLE}} in site/app/config/config.php then check on [https://activities.sugarlabs.org activities.sugarlabs.org] with a browser other than Browse that an activity compatible with the release is listed.
	{{Anchor\|Fructose}}		{{Anchor\|Fructose}}

Quozl: /* Sugar release cycle */

2017-09-09T01:28:53Z

Sugar release cycle

← Older revision		Revision as of 21:28, 8 September 2017
Line 113:		Line 113:

	* Ensure that all the module releases are available by the scheduled date.		* Ensure that all the module releases are available by the scheduled date.
	* ~~Construct a sugar-jhbuild moduleset out of them.~~ Run automatic and manual QA on it.		* Run automatic and manual QA on the releases.
	* If issues arise coordinate with the relevant module maintainers to solve them.		* If issues arise coordinate with the relevant module maintainers to solve them.
	* Announce the release on sugar-devel@lists.sugarlabs.org, including ~~a reference to the sugar-jhbuild moduleset,~~ references to each source module and a global list of changes.		* Announce the release on sugar-devel@lists.sugarlabs.org, including references to each source module and a global list of changes.

	=== Roadmap Update ===		=== Roadmap Update ===

	The Development Team's [[{{Upcoming Stable Release}}/Roadmap\|Roadmap]] is updated at the beginning of each release cycle by the release team. It ~~includes~~:		The Development Team's [[{{Upcoming Stable Release}}/Roadmap\|Roadmap]] is updated at the beginning of each release cycle by the release team. It may include:

	* Detailed schedule of release dates and freeze points.		* Detailed schedule of release dates and freeze points.
Line 127:		Line 127:

	=== Feature freeze ===		=== Feature freeze ===
	By Feature Freeze all new features have to be complete, reviewed and pushed to the repository. "Feature" should be interpreted as "Functionality" or "Ability". Bug fixes of existing features are not affected.		When a Feature Freeze is scheduled, all new features have to be complete, reviewed and pushed to the repository. "Feature" should be interpreted as "Functionality" or "Ability". Bug fixes of existing features are not affected.

	This allows developers to concentrate on refining the new features instead of adding yet more functionality.		This allows developers to concentrate on refining the new features instead of adding yet more functionality.
Line 134:		Line 134:

	=== UI Freeze ===		=== UI Freeze ===
	~~Major~~ UI revisions or changes must be done before this date.		When a UI Freeze is scheduled, major UI revisions or changes must be done before this date.

	This encourages developers to focus on stability and bug-fixing rather than UI changes. At this point, documentation writers do not have to worry that their work will become outdated.		This encourages developers to focus on stability and bug-fixing rather than UI changes. At this point, documentation writers do not have to worry that their work will become outdated.
Line 141:		Line 141:

	=== String cooling===		=== String cooling===
	~~String~~ changes have to be announced, but no exceptions have to be requested. As soon as the change is committed in git, notify the [http://lists.laptop.org/mailman/listinfo/localization localization@lists.laptop.org localization list] about it.		When a string freeze is scheduled, string changes have to be announced, but no exceptions have to be requested. As soon as the change is committed in git, notify the [http://lists.laptop.org/mailman/listinfo/localization localization@lists.laptop.org localization list] about it.

	=== String Freeze===		=== String Freeze===
	~~After this date~~ every string change has to be requested and to be approved. Please send an exception to the [http://lists.laptop.org/mailman/listinfo/localization localization@lists.laptop.org localization list] and [http://lists.sugarlabs.org/listinfo/sugar-devel sugar-devel@lists.sugarlabs.org] if you need to break the string freeze and ask for an exception. The localization team lead and two members of the release team need to approve such a break.		When a string freeze is scheduled, after the scheduleddate every string change has to be requested and to be approved. Please send an exception to the [http://lists.laptop.org/mailman/listinfo/localization localization@lists.laptop.org localization list] and [http://lists.sugarlabs.org/listinfo/sugar-devel sugar-devel@lists.sugarlabs.org] if you need to break the string freeze and ask for an exception. The localization team lead and two members of the release team need to approve such a break.

	=== Stabilizing ===		=== Stabilizing ===
	~~In the~~ stabilizing phase we request every bug fix to be tied to a ticket including a testing plan. Please add the testcase in the ticket comment field. You need to mark it with \|TestCase\|. This adds better readability and our script that pulls together the test cases for each release is able to find it as well. For example:		When a stabilizing phase is scheduled, we request every bug fix to be tied to a ticket including a testing plan. Please add the testcase in the ticket comment field. You need to mark it with \|TestCase\|. This adds better readability and our script that pulls together the test cases for each release is able to find it as well. For example:
	\|TestCase\|		\|TestCase\|
	Click on Browse, Read, Pippy icons in the homepage and make sure all of them starts correctly.		Click on Browse, Read, Pippy icons in the homepage and make sure all of them starts correctly.

	=== Hard code freeze ===		=== Hard code freeze ===
	When ~~the~~ hard code freeze is in effect, each and every code change should be approved by the release team. Only critical fixes will be considered. To request approval send mail to sugar-devel@lists.sugarlabs.org, including the patch and a detailed description of the changes, the benefits and the risks. Approval will have to be granted by two [[Development Team/Release/Contacts#People\|members]] of the team.		When a hard code freeze is in effect, each and every code change should be approved by the release team. Only critical fixes will be considered. To request approval send mail to sugar-devel@lists.sugarlabs.org, including the patch and a detailed description of the changes, the benefits and the risks. Approval will have to be granted by two [[Development Team/Release/Contacts#People\|members]] of the team.

	=== Branching ===		=== Branching ===

	After the final release of a module, a branch ~~should~~ be created to host further stable development. Please use a name in the form: sucrose-XXX (for example sucrose-0.84). Each module maintainer is responsible to inform the [http://lists.sugarlabs.org/listinfo/sugar-devel sugar-devel@lists.sugarlabs.org] and [http://lists.laptop.org/mailman/listinfo/localization localization@lists.laptop.org] lists about the branch.		After the final release of a module, a branch may be created to host further stable development. Please use a name in the form: sucrose-XXX (for example sucrose-0.84). Each module maintainer is responsible to inform the [http://lists.sugarlabs.org/listinfo/sugar-devel sugar-devel@lists.sugarlabs.org] and [http://lists.laptop.org/mailman/listinfo/localization localization@lists.laptop.org] lists about the branch.

	A new branch is created on the Pootle server, e.g., Fructose-0.96 and Fructose-0.98. The Localization team (the coordinator of a translation team) may push translations to any or all of the corresponding branches of your project. Changes to your master branch are not necessarily intended for the release branches as well.		A new branch is created on the Pootle server, e.g., Fructose-0.96 and Fructose-0.98. The Localization team (the coordinator of a translation team) may push translations to any or all of the corresponding branches of your project. Changes to your master branch are not necessarily intended for the release branches as well.

Quozl: /* Fructose (base activity) modules */

2017-09-08T23:59:02Z

Fructose (base activity) modules

← Older revision		Revision as of 19:59, 8 September 2017
Line 57:		Line 57:
	===<abbr title="Fructose, the base set of demonstration activities">Fructose</abbr> (base activity) modules===		===<abbr title="Fructose, the base set of demonstration activities">Fructose</abbr> (base activity) modules===
	* Check out the branch of the project repository,		* Check out the branch of the project repository,
	* Make a source tarball, which for most activities is done by {{Code\|bundlebuilder}} via {{Code\|setup.py}} and will place the ~~tarball~~ in the {{Code\|dist/}} directory:		* Make the source tarball and bundle, which for most activities is done by {{Code\|bundlebuilder}} via {{Code\|setup.py}} and will place the result in the {{Code\|dist/}} directory:
	python setup.py dist_source		python setup.py dist_source
			python setup.py dist_xo
	ls -l dist/		ls -l dist/
	* Create a git tag to reference the release. The tag name should be in the vXXX form (for example v20).		* Create a git tag to reference the release. The tag name should be in the vXXX form (for example v20).
	git tag v20		git tag v20
	* Test it carefully, to make sure it starts inside Sugar,		* Test it carefully, to make sure it starts inside Sugar,
	* Upload it to a stable location. You need a developer account with Sugar Labs to be able to upload there.		* Upload the tarball to a stable location. You need a developer account with Sugar Labs to be able to upload there.
	The preferred location for fructose components is:		The preferred location for fructose components is:
	shell.sugarlabs.org:/upload/sources/sucrose/fructose/ (module_name)/		shell.sugarlabs.org:/upload/sources/sucrose/fructose/ (module_name)/
	which translates to:		which translates to:
	http://download.sugarlabs.org/sources/sucrose/fructose/ (module_name)/		http://download.sugarlabs.org/sources/sucrose/fructose/ (module_name)/
	* Push the release tag to the project repository,		* Push the release tag to the project repository,
	git push --tags		git push --tags
	* ~~Send an announce mail~~ to ~~sugar-devel@lists~~.sugarlabs.org, with ~~[RELEASE] in the subject. The form will be decided by each maintainer but it should at least include~~ a ~~reference to the source code tarball and an~~ high level, user oriented list of changes.		* Upload the bundle to activities.sugarlabs.org, with a high level, user oriented list of changes, which will cause a release mail to be sent to sugar-devel@lists.sugarlabs.org.

	=== Using the release script ===		=== Using the release script ===

Quozl: /* Using the release script */

2017-09-08T23:55:20Z

Using the release script

← Older revision		Revision as of 19:55, 8 September 2017
Line 73:		Line 73:

	=== Using the release script ===		=== Using the release script ===
	For both, fructose and glucose components you can use the release script in [~~http~~://~~git~~.sugarlabs~~.org/projects~~/sugar-tools sugar-tools] to do the above tasks in one go.		For both, fructose and glucose components you can use the release script in [https://github.com/sugarlabs/sugar-tools sugar-tools] to do the above tasks in one go.

	You can check out the available commands (Note, the script does try to release the software of the directory you are currently in):		You can check out the available commands (Note, the script does try to release the software of the directory you are currently in):

Quozl: /* Glucose (base) modules */

2017-09-08T23:26:11Z

Glucose (base) modules

← Older revision		Revision as of 19:26, 8 September 2017
Line 50:		Line 50:
	http://download.sugarlabs.org/sources/sucrose/glucose/ (module_name)/		http://download.sugarlabs.org/sources/sucrose/glucose/ (module_name)/
	* Push the release tag to the project repository,		* Push the release tag to the project repository,
			git push --tags
	* Announce by mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user oriented list of changes.		* Announce by mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user oriented list of changes.
	* When the {{Code\|sugar}} module is released, update the Activity Library default stable release; the variable {{Code\|SITE_SUGAR_STABLE}} in site/app/config/config.php then check on [https://activities.sugarlabs.org activities.sugarlabs.org] with a browser other than Browse that an activity compatible with the release is listed.		* When the {{Code\|sugar}} module is released, update the Activity Library default stable release; the variable {{Code\|SITE_SUGAR_STABLE}} in site/app/config/config.php then check on [https://activities.sugarlabs.org activities.sugarlabs.org] with a browser other than Browse that an activity compatible with the release is listed.

Quozl: /* Fructose (base activity) modules */

2017-09-08T23:25:48Z

Fructose (base activity) modules

← Older revision		Revision as of 19:25, 8 September 2017
Line 67:		Line 67:
	which translates to:		which translates to:
	http://download.sugarlabs.org/sources/sucrose/fructose/ (module_name)/		http://download.sugarlabs.org/sources/sucrose/fructose/ (module_name)/
	* Push the ~~git~~ tag to the project repository,		* Push the release tag to the project repository,
	git push --tags		git push --tags
	* Send an announce mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user oriented list of changes.		* Send an announce mail to sugar-devel@lists.sugarlabs.org, with [RELEASE] in the subject. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user oriented list of changes.