Development Team/Release: Difference between revisions

(4 intermediate revisions by the same user not shown)

Line 51:

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

* One week later, check that the corresponding packages have been updated, and if not contact the downstream packager.

===<abbr title="Fructose, the base set of demonstration activities">Fructose</abbr> (base activity) modules===

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

python setup.py dist_source

Line 71:

Line 74:

* Push the release tag to the project repository,

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.

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

~~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):~~

~~./release --help~~

~~==== For sucrose activities ====~~

~~===== Before release =====~~

~~Be sure to have the same state as origin/master, git pull, git log, gitstatus, git reset --hard origin/master~~

~~===== Release =====~~

~~cd into the activity directory, run the sugar-tools 'release' script from there~~

~~~/prog/sugar-tools/release~~

~~If you want to be sure about the version you can pass the version you want it to be to the script:~~

~~~/prog/sugar-tools/release -v 0.96.5~~

~~Requirements:~~

* has to be done in a sugar shell

* user needs ssh access to sugarlabs.org

* user needs write access to the upload directory: http://download.sugarlabs.org/sources/sucrose/fructose/

~~===== Upload the .xo file to ASLO =====~~

~~Tarball is uploaded but you're not done yet, you need to upload the .xo file to ASLO manually~~.

== Sugar release cycle==

Line 184:

Line 154:

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==

@@ Line 51: / Line 51: @@
 * 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 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.
+* One week later, check that the corresponding packages have been updated, and if not contact the downstream packager.
 {{Anchor|Fructose}}
 ===<abbr title="Fructose, the base set of demonstration activities">Fructose</abbr> (base activity) modules===
 * 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:
   python setup.py dist_source
@@ Line 71: / Line 74: @@
 * Push the release tag to the project repository,
   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.
-=== Using the release script ===
-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):
- ./release --help
-==== For sucrose activities ====
-===== Before release =====
-Be sure to have the same state as origin/master, git pull, git log, gitstatus, git reset --hard origin/master
-===== Release =====
-cd into the activity directory, run the sugar-tools 'release' script from there
- ~/prog/sugar-tools/release
-If you want to be sure about the version you can pass the version you want it to be to the script:
- ~/prog/sugar-tools/release -v 0.96.5
-Requirements:
-* has to be done in a sugar shell
-* user needs ssh access to sugarlabs.org
-* user needs write access to the upload directory: http://download.sugarlabs.org/sources/sucrose/fructose/
-===== Upload the .xo file to ASLO =====
-Tarball is uploaded but you're not done yet, you need to upload the .xo file to ASLO manually.
 == Sugar release cycle==
@@ Line 184: / Line 154: @@
 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==