1,285
edits
Changes
Jump to navigation
Jump to search
Line 51:
Line 51: − + + Line 72:
Line 73: − − === 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. Line 184:
Line 152: − − == 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.
Development Team/Release (view source)
Revision as of 16:44, 2 November 2017
, 16:44, 2 November 2017no edit summary
* 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.
* One week later, check that the corresponding packages have been updated, and if not contact the downstream packager.
{{Anchor|Fructose}}
{{Anchor|Fructose}}
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, user 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==
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.
==Related pages==
==Related pages==