Skip to end of metadata
Go to start of metadata

ATutor Release Cycle


This document outlines the ATutor release process, intended for the manager of a release, and for general interest for anyone who would like to know how ATutor releases happen.

ATutor release cycles occur approximately bi-annually for major releases (June & December) , and occasionally in between scheduled releases for minor bug fix or new feature releases. Depending on the extent of development done, a release may take 30 to 45 days to complete, with a number of betas released (beta1, beta2 etc) weekly. Each beta is released to solicit feedback, and any bugs reported are fixed, or adjustments made where needed before a subsequent beta is released. When bug reports trickle off, and the code is considered stable (enough) a first release candidate (RC1, RC2 etc.) is made publicly available. After 1 to 2 weeks, if no significant issues are identified, the final stable release is published, otherwise fixes are made and another RC version is made public, and the RC process repeated.

Upgrade scripts must be complete for RC versions, though they may not be complete for beta versions.

Release Day

  1. Review the bug tracker, close all resolved bugs, and identify any last minute bugs/adjustments
  2. Generate a bundle using the latest file for ATutor, in the webedit user's home directory in the /bundle sub-directory. Append the release version number as the argument when running the bundle script (eg ./ 1.6.3 )
  3. Install the generated bundle on a local development system, and scan through the installation, creating a course, adding users, creating content, importing and exporting CC/QTI/CP content, tests etc. Scan though student/Instructor/ admin panels to ensure there is no missing language, particularly focusing on new or modified features. Much of the testing for these and other features would have been done previous to release day, but repeat tests on critical functionality.
  4. Upgrade from the latest previous version to the bundled version on a local dev environment. The version to be upgraded should include basic content, including content pages and a4a content, check the editor's achecker webservice. Create and take test and review it results and data, and ensure that courses and users remain intact.
  5. Upgrade from the previous major version (e.g 1.5* to 1.6.4) in addition to upgrading from the immediate previous version (e.g. 1.6.3 to 1.6.4).
  6. Make adjustments if needed, and generate a new bundle is needed. It may be necessary to repeat steps 3 to 5 after the new bundle is generated to ensure fixes are working properly.
  7. Prepare release news in text format. The news release should include the subject line, repeated as the heading of the news item “ATutor x.x.x Released”, followed by the date after the heading in the body of the message. Then follow with a paragraph explaining the purpose of the release (major, minor, bugs, features, etc.) in the first section, and include encouragement to upgrade, together no longer that a few lines, followed by links to the download and demo pages. It is important that the first part be short and concise with links for purposes of getting the news posted to the sourceforge home page, and so others can easily copy the headline, byline, and links for re-posting elsewhere.
  8. Add below the above mentioned release summary, a list of “New Features in the Release” which outlines all significant features in the release. Highlight the title of each new feature's heading in bold using asterisks.
  9. If appropriate, mention “Features coming in the next release” in a section below, and add a section to invite “Translators” to update their translations, along with the approximate number of new translation items. Leave these sections out if there isn't a clear picture of features for the next release, or if there are few or no language items to be translated.
  10. Update the Roadmap on, either indicate that features are done, or move them to the changelog.
  11. Update the Changelog page. Often this is a copy of the new features list in the news release, with a little extra detail. Set the date to the actual release date.
  12. Upgrade the demo site, or replace the current demo with a fresh install if there is a lot of junk in the old demo. If the later, create a user demo with password demo, and create an “ATutor Demo Course” and populate it with the old ATutor Howto 1.4.3 course backup, found in the Content section of It includes content and tests. Go through the course and create a little default content where “none found” is displayed. Turn on any new modules that were introduced in the release, and write a short introduction to the changes in the release as a News item (Manage>Announcements) and past the changelog into the message.
  13. Check the login form on at atutor/demo.php. Adjust if necessary. Edit the /login.php file of the upgraded demo installation to allow remote login. See the comments in the file.
  14. When the demo site has been successfully upgraded, create a tag in GitHub labelled in the format atutor_1_6_4.
  15. Update the bundled ATutor by adding the latest commit id for the GitHub tag to constants (e.g define('AT_GITHUB_RELEASE_COMMIT', 'ef64e66bd1fcd058a6bb653778ba44202efad589'));
  16. Using the ATutor Language Manager on the site, create a tag of the language database by clicking on “Add Stable Release”. This should generate the directory Publish the English language, and any other languages that are complete.
  17. Add a new language pack block to the atutor translations page atutor/translate/index.php, by manually copying an existing block, and changing the version number (as webedit). At the same time update the version number in the “Now Translating” section to the left on that page to point to the new tag in the language db.
  18. At Sourceforge upload the bundle with appropriate version number attached to the file (e.g. Atutor-1.6.3.tar.gz). You will need to login to sourceforge as an ATutor admin. Cindy and Harris currently have admin privileges.
  19. Sourceforge news release. Post the news release described above to Sourceforge.
  20. Sourceforge mailing list, send the whole news release to it. It is a moderated list, so you will need to login to the mailman list admin to approve the post.
  21. Post news release to the home page, including the version number of the release, the date, a brief description of the features, or the purpose (major, features, bug fixes etc.) and links to the download and demo pages. Also include a link to the sourceforge news release posted above, where people can go for full details. Currently this news is added manually by editing the HTML of the home page (this needs to be automated, and replaced with the news posting, in the next step.
  22. As the admin, post the news release summary to the News utility. This inserts a headline with a link to the News page on the home page, which include an RSS feed for updating other sites that link to the feed.
  23. Post the news summary to the Community forum, and the Support forum with the same links included in the other news summary posts.
  24. Mailing List. Open the mailing list script (you know where this is if you're authorized to use it). Send the mailing in test mode (default) and review the mail sent to ensure formatting etc. is all in order. Harris and Greg, and receive the test email.Update the version number in check_atutor_version.php, found in the root directory of This will inform current users that there is a new version available.
  25. Set the .forward email address for to email address of the person managing the mailing (talk to Jamon). Bounced email will be sent to so you will want to setup a filter to collect undelivered mail.
  26. Once the news email is confirmed clean and formatted correctly, and is set up, press the “Clean Sent Mails” button in the mailing list screen to clear the list of emails sent in the previous mailing. The uncheck the Test Only checkbox. Click “Send Promo” to start the mailing. Mailing currently take about 8 hours, after which a note will be sent to info@atutor confirming the mailing completed successfully.
  27. Mail is sent 300 (or something like that) at a time. Monitor the mailing. Restart if it stalls. It will restart where it left off sending to the next email in the sequence.
  28. Send a note to, which demo's the ATutor admin backend, and let them know to upgrade.
  29. In the days following search Google for “ATutor” and where appropriate, post the release news, or send a note to the site's maintainer to update their listing. Generally just sites that distribute ATutor or list it in a directory of some sort. Not sites using ATutor.
  30. Wait a few days for the undelivered mails to be collected by the filter you created in your mail client, then extract the email addresses and remove them from the mail_subscriptions table. (this needs to be automated, currently using a local script that copies email addresses out of the Undelivered folder in my mail client. Then Harris runs a script to extract the valid addresses from the table. You'll likely need to do this again a week of so later after the delayed delivery bounces come back. (This is currently being automated. Bounces will be collected in the account, linked from the mailing scripts, which will provide a way to clean bounce mail from the mailing list table in the database, and clean the bounced mail out of the info@atutor mail account1
  • No labels