Version 51 (modified by Fran Boon, 8 years ago) ( diff )


Release Process

We plan to make release versions of Eden.

This will entail:

  • Creating a QA branch
    • 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


Tags will be added based on the following schema:


The VERSION string will include the Tag + the number of commits since the last tag + the hash of the commit

The Major release number will only change if we:

  • change the API in backward-incompatible ways
  • release a new trunk

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 an 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 user communications.

Git docs on Tags:

Branch Tags

If a Branch of the code is made on GitHub to manage releasesfor a deployment, then it's version will be appended to that of the Stable branch, so


Upgrade Scripts

For every update that requires it, an Upgrade script will be added to:


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:


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:


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:


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/

Update Language Files

python -S eden -R applications\eden\static\scripts\tools\

Merge any updates from Pootle

Export Application

This could be scripted:

cd /home/web2py
# @ToDo: Clean
# Compile
python -S eden -M -R applications/eden/static/scripts/tools/
# @ToDo: Catch errors
# @ToDo: Pack
# @ToDo: Download with filename


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.

Update Windows Installers

Update Wiki

Update Demo

  • Update Web2Py if necessary
    cd /home/web2py/applications/eden
    git pull

Alternate approach:

See Also


Note: See TracWiki for help on using the wiki.