Release Process Workflow

Release a new version of Elgg.

This is the process the core team follows for making a new Elgg release. We have published this information in the spirit of openness, and to streamline onboarding of new team members.


  • SSH access to
  • Commit access to
  • Admin access to
  • Access to Twitter account
  • Node.js and Yarn installed
  • Sphinx installed (easy_install sphinx && easy_install sphinx-intl)
  • Transifex client installed (easy_install transifex-client)
  • Transifex account with access to Elgg project

Merge commits up from lower branches

Determine the LTS branch. We need to merge any new commits there up through the other branches.

For each branch

Check out the branch, make sure it’s up to date, and make a new work branch with the merge. E.g. here we’re merging 1.12 commits into 2.0:

git checkout 2.0
git pull
git checkout -b merge112
git merge 1.12


If already up-to-date (no commits to merge), we can stop here for this branch.

If there are conflicts, resolve them, git add ., and git merge.

Make a PR for the branch and wait for automated tests and approval by other dev(s).

git push -u my_fork merge112

Once merged, we would repeat the process to merge 2.0 commits into 2.1.

First new stable minor/major release

Update the Support policy to include the new minor/major release date and fill in the blanks for the previous release.

Update the file badges to point to the correct new release numbers.

Prepare the release

Bring your local git clone up to date.

Merge latest commits up from lowest supported branch.

Visit<new>...<old> and submit the PR if there is anything that needs to be merged up.

Install the prerequisites:

yarn install elgg-conventional-changelog
easy_install sphinx
easy_install sphinx-intl
easy_install transifex-client


On Windows you need to run these command in a console with admin privileges

Run the release.php script. For example, to release 1.12.5:

git checkout 1.12
php .scripts/release.php 1.12.5

This creates a release-1.12.5 branch in your local repo.

Next, manually browse to the /admin/site_settings page and verify it loads. If it does not, a language file from Transifex may have a PHP syntax error. Fix the error and amend your commit with the new file:

# only necessary if you fixed a language file
git add .
git commit --amend

Next, submit a PR via GitHub for automated testing and approval by another developer:

git push your-remote-fork release-1.12.5

Tag the release

Once approved and merged, tag the release:

git checkout release-${version}
git tag -a ${version} -m'Elgg ${version}'
git push --tags origin release-${version}

Or create a release on GitHub

  • Goto releases
  • Click ‚Draft a new release‘
  • Enter the version
  • Select the correct branch (eg 1.12 for a 1.12.x release, 2.3 for a 2.3.x release, etc)
  • Set the release title as ‚Elgg {version}‘
  • Paste the part related to this release in the description

Some final administration

  • Mark GitHub release milestones as completed
  • Move unresolved tickets in released milestones to later milestones

Update the website

Build zip package

Use elgg-scripts/build/ to generate the .zip file. Run without arguments to see usage.

# login as user deploy
sudo -su deploy

# regular release
./ master 3.0.0 /var/www/

# MIT release
./ master 3.0.0-mit /var/www/


For Elgg 2.x releases use the 2.x branch of the starter-project (eg. ./ 2.x 2.0.4 /var/www/

  • Verify that vendor/elgg/elgg/composer.json in the zip file has the expected version.
  • If not, make sure GitHub has the release tag, and that the starter project has a compatible elgg/elgg item in the composer requires list.

Building 1.x zip packages

Use elgg-scripts/build/ to generate the .zip file. Run without arguments to see usage.

# regular release
./ 1.12.5 1.12.5 /var/www/

# MIT release
./ 1.12.5 1.12.5-mit /var/www/

Update download page

composer update elgg/community


composer update
  • Commit and push the changes
  • Pull to live site
cd /var/www/ && sudo su deploy && git pull
  • Update dependencies
composer install --no-dev --prefer-dist --optimize-autoloader
  • Go to community admin panel
    • Flush APC cache
    • Run upgrade

Make the announcement

This should be the very last thing you do.

  1. Open<tag>/ and copy the contents for that version
  2. Sign in at and compose a new blog with a summary
  3. Copy in the CHANGELOG contents, clear formatting, and manually remove the SVG anchors
  4. Add tags release and elgg2.x where x is whatever branch is being released
  5. Tweet from the elgg Twitter account