= Release Process = [[TOC]] We plan to make release versions of Eden. This will entail: * Creating a QA branch (ideally) - features have final integration testing done here before being pushed to the Stable branch * Creating a Stable branch - deployments should be done from this branch * Adding Tags to Releases * Building upgrade scripts == Tagging == Tags will be added based on the following schema: {{{ [BranchName]-[Major].[Minor].[Sub] }}} The VERSION string will displayu the Tag. If there are commits after the last SubRelease then they also append the number of commits since the last tag + the hash of the commit: {{{ [BranchName]-[Major].[Minor].[Sub]-#-[Hash] }}} These commits in between SubReleases should never be visible to users (except maybe on a Dev server) The Major version number will only change if we: * create a new parallel branch which would become the new trunk * probably this would be because we change the API in backward-incompatible ways The Minor release number indicates the normal release. * Upgrades between these should be accompanied by some Change Management as users will see some differences (this could be just a mail saying 'some things may change' or could be full User Acceptance Testing) * These will often require an update script The Sub release number indicates a maintenance update to the release. Sub-releases can introduce new features, but they would normally not: - replace feature sets - remove feature sets - fundamentally change the logic/semantics of a feature set Sub-releases may still require an upgrade script, but usually won't. They normally wouldn't need such stringent user communications or documentation updates. Git docs on Tags: * https://git-scm.com/book/en/v2/Git-Basics-Tagging == Deployment Branches == If a Branch of the code is made to manage releases for a deployment, then there are 2 options: * If any significant development is done then it should be based initially off trunk * If no development is planned (just backporting any critical bugfixes/minor tweaking) then it can be based off stable right away Once a Development branch has moved into Production then it should move to being based off Stable once the requisite features have merged into stable (or could even start using vanilla stable releases as deployment branches should converge with that anyway). Branches based off Stable should have it's version appended to that of the Stable branch, so: {{{ [BranchName]-[Major].[Minor].[Sub]-[BranchRelease].[Sub] }}} Branches based off Trunk should have it's version appended to the Major Version of the Trunk branch, so: {{{ [BranchName]-[Major]-[BranchRelease].[Sub] }}} If a production site has another Development phase (or is being developed continuously) then a new Development branch should be created for that, again starting from Trunk. This can be deployed to the Dev server and then the test server when ready to move it into Production. Again, after the move to production, then it should move to being based off Stable once the requisite features have merged into stable == Upgrade Scripts == For every update that requires it, an Upgrade script will be added to: {{{ eden/static/scripts/upgrade/1.a.b-1.a.c.py }}} The 'pull' script will be modified to call this script automatically === Template Upgrade Scripts === If there are template-specific changes for an update then these will be found in: {{{ eden/modules/templates/TEMPLATE/upgrade/1.a.b-1.a.c.py }}} This will be checked for automatically by the 'pull' script === Branch Upgrade Scripts === Typically a Branch will be using a custom Template (even if this is a thin layer on top of other templates). Branch upgrade scripts will therefore be in: {{{ eden/modules/templates/TEMPLATE/upgrade/1.a.b_d.e-1.a.b_d.e.py or eden/modules/templates/TEMPLATE/upgrade/1.a.b_d.e-1.a.c_d.e.py }}} This will be checked for automatically by the 'pull' script. If there is no branch-specific upgrade script yet there is one for the underlying stable upgrade then the pull script should detect this & allow the user to run this instead of nothing or bail & revert. == Old Info == When making a Stable Branch from which to build releases, we need to do these tasks: Check that all works with a released version of Web2Py Ensure included files sane: * README * VERSION * INSTALL * CHANGELOG === Clear Database === To clear database of test data & reset to defaults: * Close Web2Py * Delete all files from {{{/databases}}} & {{{/uploads}}} Clean the files which are created by the deployment-templates of all personal data (i.e. overwrite with version from deployment-templates): * cron/crontab * models/000_config.py === Update Language Files === {{{ python web2py.py -S eden -R applications\eden\static\scripts\tools\languages.py }}} Merge any updates from [http://pootle.sahanafoundation.org Pootle] === Export Application === * Clean: http://127.0.0.1:8000/admin/default/cleanup/eden * Compile: http://127.0.0.1:8000/admin/default/compile_app/eden * NB If this Errors then this is likely to be a faulty view (e.g. missing a final {{pass}}) which needs resolving before the release to avoid performance issues. * Pack all: http://127.0.0.1:8000/admin/default/pack/eden * Save as: {{{web2py.app.eden-0.x.w2p}}} This could be scripted: {{{ cd /home/web2py # @ToDo: Clean # Compile python web2py.py -S eden -M -R applications/eden/static/scripts/tools/compile.py # @ToDo: Catch errors # @ToDo: Pack # @ToDo: Download with filename }}} === Test === Import the app with a new name & Test === Upload to !LaunchPad === '''Note: As of January 2012, BZR/Launchpad info for eden is deprecated. Please visit the GitHub page. Thanks.'''[[BR]] === Update Windows Installers === * InstallationGuidelinesWindowsMaintenance * InstallationGuidelinesWindowsPythonInstaller === Update Wiki === * InstallationGuidelinesWindows * InstallationGuidelinesLinux * [wiki:InstallationGuidelinesMacOSX InstallationGuidelinesMacOSX] * [wiki:#News] === Update Demo === * [wiki:DeveloperGuidelinesWeb2PyUpdate Update Web2Py] if necessary {{{ cd /home/web2py/applications/eden git pull }}} Alternate approach: * Start appadmin: /root/web2py_admin.sh * Configure SSH Tunnel: http://web2py.com/AlterEgo/default/show/143 * Access via SSH Tunnel: http://127.0.0.1:8001/admin * Upload application: http://127.0.0.1:8001/admin/default/site * Reboot VPS (free up resources for improved performance) == See Also == * [http://systers.org/systers-dev/doku.php/svaksha:release_management_notes Systers release process] * [http://www.youtube.com/watch?v=i7pkyDUX5uM OpenBSD release process] * [http://docs.google.com/Doc?docid=0AbG7fqVva7L3ZGZmNXprc3RfMGZjODNudmhu&hl=en Agasti proposed released process] ---- DeveloperGuidelines