Joomla

Difference between revisions of "Release procedure and checklist"

From Joomla! Documentation

(→‎Sites to update: Note about updating developer site, add API site)
(36 intermediate revisions by 6 users not shown)
Line 3: Line 3:
 
[[Category:Development]]
 
[[Category:Development]]
  
There is a general checklist when a version of Joomla! is released. Keep in mind that a major release differs a lot from a [[Minor Release]] or even a [[Maintenance Release]]. The checklist here describes the steps that need to be done for (at least) [[Maintenance Release]] and [[Minor Release]].
+
This is a general checklist when a version of Joomla! is released. Keep in mind that a major release differs a lot from a [[Minor Release]] or even a [[Maintenance Release]]. The checklist here describes the steps that need to be done for (at least) [[Maintenance Release]] and [[Minor Release]].
  
 
== Release checklist ==
 
== Release checklist ==
 
 
It depends on the [[Development Cycle]] when the checklist is triggered. A release can be done during every stage of the [[Development Cycle]], it does not matter if you release a beta or a stable version, this is a general checklist that can be used when releasing a new version of Joomla! The checklist starts when it's decided to release a version:
 
It depends on the [[Development Cycle]] when the checklist is triggered. A release can be done during every stage of the [[Development Cycle]], it does not matter if you release a beta or a stable version, this is a general checklist that can be used when releasing a new version of Joomla! The checklist starts when it's decided to release a version:
  
 
=== Preparation phase ===
 
=== Preparation phase ===
# Communication pre-release: check with all Working Group Coordinators for status
+
# Communication pre-release: check with PLT on timing
# Communication pre-release: check with Lead Developers for status
+
# Communication pre-release: inform Bug Squad and LT's about timing
# Communication pre-release: inform Bug Squad and Development Team of upcoming release
 
 
# Decision: when the above has positive result, set a date and time for release
 
# Decision: when the above has positive result, set a date and time for release
 
# Communication pre-release: inform Global Moderators about upcoming release
 
# Communication pre-release: inform Global Moderators about upcoming release
# Communication pre-release: check availability and assign release tasks to Core and work-group members.
+
# Communication pre-release: check availability and assign release tasks to JBS and PLT members
# Close trunk on predefined date and time (Development Coordinator, also sends an e-mail to development list).
+
# Minimum 7 days prior to release: freeze trunk for language changes
# Image for front page download module, has to be modified for the release.
+
# Minimum 3 days prior to release: freeze trunk for all changes, draft release notes to translation teams, package release candidate for testing
# Contact foundation work group for creation of Front page announcement.
+
# Day of release: set project flags on Joomlacode, update web pages
# Determine release name
+
# Announce on forum, announce to LT's
  
=== Pre-execution phase ===
+
=== Pre-release phase ===
 
# Apply latest translations (need to be delivered by translation work group).
 
# Apply latest translations (need to be delivered by translation work group).
 
# Create test package.
 
# Create test package.
# Offer test package to testers: [[Bug Squad]] members, [[Development Team ]] members, translation members
+
# Offer test package to testers: [[Bug Squad]] members, [[Development Team]] members, translation members
 
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
 
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
 +
# Draft the release notes on Joomla.org and post draft to the [http://forum.joomla.org/viewforum.php?f=54 private translation forum].
 +
# Obtain any CVE numbers needed.
 +
# Draft security notices as needed and leave unpublished on developer.joomla.org.
  
=== Execution phase ===
+
=== Release phase ===
# Check for security fixes.
+
# Check with JSST for security fixes.
# Change version information (libraries/joomla/version.php)
+
# Create release notes document on joomla.org and post copy to translation forum.
 +
# Ensure version information is correct (libraries/cms/version/version.php)
 +
# Update administrator/manifests/files/joomla.xml file for version number and date.
 +
# Make sure there is at least one .sql update file in the com_admin/sql/updates/<db> folders (to update the database schema).
 +
# Check language/en-GB/en-GB.files_joomla.sys.ini file for version number (not needed for minor update).
 
# Enable install check.
 
# Enable install check.
# Add entry in CHANGELOG.php file
+
# Commit and tag release locally, *DO NOT* push to GitHub until post release (especially if security fixes are merged)
# Update administrator/manifests/files/joomla.xml file for version number and date.
 
 
# Package build.
 
# Package build.
# Offer test package to testers: [[Bug Squad]] members, [[Development Team ]] members, translation members
+
# Offer test package to testers: [[Bug Squad]] members, [[Development Team]] members, translation members
 
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
 
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
 +
# Update developer.joomla.org
 +
## Create a new release notes menu item. There is a release notes menu and you can copy the menu item for the previous release there and modify appropriately.
 +
### 2.5 - Just fill in the options with the tracker item #'s, which you can get from the GitHub commit log
 +
### 3.x - Enter the dates for the release period and exclude 2.5 specific items
 +
## Add Bug Squad Contributors module to the newly created release notes page.  Copy the module for the previous release and change the dates and menu assignments for the new module.  This produces the list of active Bug Squad members for a release period.
 
# Add package to joomlacode.org
 
# Add package to joomlacode.org
## Before the release is public, set the joomlacode package flags as follows: Visible=No, Public=No, Require Login=Yes.
+
## Before the release is public, set the JoomlaCode package flags as follows: Visible=No, Public=No, Require Login=Yes.
 
## Set the Release flags as follows: Visible=Yes, Released=Yes.
 
## Set the Release flags as follows: Visible=Yes, Released=Yes.
 
## Once package is released, change the Package flags to Visible=Yes, Public=Yes, Require Login=No.
 
## Once package is released, change the Package flags to Visible=Yes, Public=Yes, Require Login=No.
 
## Change the prior version package to Visible=No but leave the prior version release flags as they are.
 
## Change the prior version package to Visible=No but leave the prior version release flags as they are.
# Publish security notices on developer site.
 
# Publish announcement on joomla.org and the forum, change download article links
 
# Make static copy of front page with announcement to be used if server load becomes critical.
 
 
# Update XML file on site for the new version number information.
 
# Update XML file on site for the new version number information.
# Publish announcement on forum.
+
## FTP connect to update1.joomla.org and Navigate to www/core
 +
## All releases
 +
### Change version attribute in list.xml (don't add new line except when incrementing major/minor version numbers)
 +
## LTS Release
 +
### Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension.xml
 +
## STS Release
 +
### Navigate to www/core/sts
 +
### Change version attribute in list_sts.xml (don't add new line except when incrementing major/minor version numbers)
 +
### Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension_sts.xml
 +
## Test auto update from prior version(s) (make sure XML files have been copied to the SDN on update.joomla.org first)
 +
### All releases
 +
#### Navigate to www/core/test
 +
#### Change version attribute in list_test.xml (don't add new line except when incrementing major/minor version numbers)
 +
### LTS
 +
#### Upload patch package to this folder
 +
#### Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension_test.xml
 +
### STS
 +
#### Navigate to www/core/teststs
 +
#### Upload patch package to this folder
 +
#### Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension_sts.xml
 +
# Update Joomla.org Download article
 +
# Publish security articles on developer site.
 +
# Publish release announcement on Joomla.org
 +
# Publish announcement on the forum
 +
# Update download page
 +
# Update Wiki: FAQ, Version history
 +
# Email OSM list
 +
# Create the Web Platform Installer packs and submit them
  
=== Finalization phase ===
+
=== Post-release & Finalization phase ===
# Tag SVN.
+
# Merge release branch to series development head (2.5 -> 2.5.x branch, 3.x -> master branch)
# Un-freeze the trunk, send e-mail to work groups and mailing lists ([[Development Team]] and [[Bug Squad]]).
+
# Push release changes from local to remote Github repo
# Undo install check.
+
## Security fixes (if any)
# Change content on joomla.org and dev.joomla.org (see pages to update)
+
## Version tag
# Update MD5 checksum information
+
## Version changes (SQL files, version.php, joomla.xml)
# Update nightly builds to reflect new release
+
## Install checks
 +
# Update Github repo for new version development
 +
## Remove install checks
 +
## Update version in version.php, joomla.xml, SQL files, SQL update files
 +
# Delete old release branch after confirming all commits are merged to series development head
 +
# Close security issues in security tracker
  
 
=== Pages to update ===
 
=== Pages to update ===
 +
#Global:
 +
#* [http://developer.joomla.org/development-status.html Development Status]
 +
#* [http://www.joomla.org/download Download Page]
  
#Global:
+
=== Sites to update ===
#1.5:
+
#PLT Owned sites
#* Create new Wiki article called 'Category:Version 1.5.X FAQ'. Add an overall note for the release in the body of the article using the previous version as a Guide. Insert the following into the article:  <nowiki>[[Category:Version 1.5 FAQ]]</nowiki>. Include a link to the 'Category:Version 1.5.x FAQ' page in the Release notes.
+
#* [http://ux.joomla.org JUX Site]
#* Update [http://docs.joomla.org/Joomla_1.5_version_history Version History]
+
#* [http://developer.joomla.org Developer Site]
#* Update [http://docs.joomla.org/Joomla!_Codenames Joomla! Codenames]
+
#** Before updating, verify the cron jobs (JoomlaCode tracker sync and language updater) do not break with the update
# 1.0:
+
#* [http://help.joomla.org Help Site (old)]
#* [http://dev.joomla.org/content/blogcategory/21/86/ Current Status]
+
#* [http://api.joomla.org API Site]
#* [http://www.joomla.org/content/blogcategory/32/66/ Latest Release]
+
#** Regenerate API docs for the new release
#* [http://www.joomla.org/content/category/5/34/78/ Changelog]
 
#* [http://www.joomla.org/content/category/5/39/95/ MD5 Sums]
 
  
 
=== Calculating Release Statistics ===
 
=== Calculating Release Statistics ===
 
+
==== Using JoomlaCode and CHANGELOG ====
 
# Extract *all* issues from Tracker into spreadsheet. Make note of the date of the last release and the number of active issues at the time of the last release.
 
# Extract *all* issues from Tracker into spreadsheet. Make note of the date of the last release and the number of active issues at the time of the last release.
 
# Set a filter on the "Closed Date" column to be "after" "the day of the last release".  
 
# Set a filter on the "Closed Date" column to be "after" "the day of the last release".  
Line 82: Line 121:
 
# Count the "number of commits" by reviewing the CHANGELOG.php file and counting the documented commits.
 
# Count the "number of commits" by reviewing the CHANGELOG.php file and counting the documented commits.
  
===Alternative Method for Stats===
+
==== Using GitHub ====
 +
# Go to https://github.com/joomla/joomla-cms/compare/<version>...master where <version> is the previous release, this is GitHub's comparison view and will give stats from the previous release tag to the currently published master
 +
# From this page, you can compile the number of commits, contributors, and files changed during the release period
 +
 
 +
==== Download Statistics ====
 +
# Go to http://joomlacode.org/gf/project/joomla/frs/?action=FrsReport
 +
# In the filter bar, set the start date to the date of the previous release and the end date to the day before the new release
 +
# The "Downloads By Package" chart is the total number of downloads for each release (i.e. 2.5.16 and 3.2.0) and includes an "Other" piece for all older version downloads
 +
# The "Downloads By Release" chart separates the packages by new install and updates
 +
 
 +
==== Alternative Method for Stats ====
 
* Fixed in SVN: Create query with close date > date of prior release and status = Fixed in SVN.
 
* Fixed in SVN: Create query with close date > date of prior release and status = Fixed in SVN.
 
* Commits: Count from CHANGELOG.php as indicated above.
 
* Commits: Count from CHANGELOG.php as indicated above.
Line 92: Line 141:
 
* Pending at time of release: query of all issues with status = Pending or Ready to Commit
 
* Pending at time of release: query of all issues with status = Pending or Ready to Commit
  
====Increase/Decrease in Active Issues====
+
==== Increase/Decrease in Active Issues ====
 
* Total active issues now = Open at time of release + Confirmed at time of release + Pending at time of release
 
* Total active issues now = Open at time of release + Confirmed at time of release + Pending at time of release
 
* This number minus the total active as of prior release is the net increase or decrease
 
* This number minus the total active as of prior release is the net increase or decrease

Revision as of 18:14, 8 December 2013


This is a general checklist when a version of Joomla! is released. Keep in mind that a major release differs a lot from a Minor Release or even a Maintenance Release. The checklist here describes the steps that need to be done for (at least) Maintenance Release and Minor Release.

Release checklist[edit]

It depends on the Development Cycle when the checklist is triggered. A release can be done during every stage of the Development Cycle, it does not matter if you release a beta or a stable version, this is a general checklist that can be used when releasing a new version of Joomla! The checklist starts when it's decided to release a version:

Preparation phase[edit]

  1. Communication pre-release: check with PLT on timing
  2. Communication pre-release: inform Bug Squad and LT's about timing
  3. Decision: when the above has positive result, set a date and time for release
  4. Communication pre-release: inform Global Moderators about upcoming release
  5. Communication pre-release: check availability and assign release tasks to JBS and PLT members
  6. Minimum 7 days prior to release: freeze trunk for language changes
  7. Minimum 3 days prior to release: freeze trunk for all changes, draft release notes to translation teams, package release candidate for testing
  8. Day of release: set project flags on Joomlacode, update web pages
  9. Announce on forum, announce to LT's

Pre-release phase[edit]

  1. Apply latest translations (need to be delivered by translation work group).
  2. Create test package.
  3. Offer test package to testers: Bug Squad members, Development Team members, translation members
  4. If problems are found during this stage, go back to fix the problem. Use the Joomla! Maintenance Procedures and repeat until tests are performed successfully.
  5. Draft the release notes on Joomla.org and post draft to the private translation forum.
  6. Obtain any CVE numbers needed.
  7. Draft security notices as needed and leave unpublished on developer.joomla.org.

Release phase[edit]

  1. Check with JSST for security fixes.
  2. Create release notes document on joomla.org and post copy to translation forum.
  3. Ensure version information is correct (libraries/cms/version/version.php)
  4. Update administrator/manifests/files/joomla.xml file for version number and date.
  5. Make sure there is at least one .sql update file in the com_admin/sql/updates/<db> folders (to update the database schema).
  6. Check language/en-GB/en-GB.files_joomla.sys.ini file for version number (not needed for minor update).
  7. Enable install check.
  8. Commit and tag release locally, *DO NOT* push to GitHub until post release (especially if security fixes are merged)
  9. Package build.
  10. Offer test package to testers: Bug Squad members, Development Team members, translation members
  11. If problems are found during this stage, go back to fix the problem. Use the Joomla! Maintenance Procedures and repeat until tests are performed successfully.
  12. Update developer.joomla.org
    1. Create a new release notes menu item. There is a release notes menu and you can copy the menu item for the previous release there and modify appropriately.
      1. 2.5 - Just fill in the options with the tracker item #'s, which you can get from the GitHub commit log
      2. 3.x - Enter the dates for the release period and exclude 2.5 specific items
    2. Add Bug Squad Contributors module to the newly created release notes page. Copy the module for the previous release and change the dates and menu assignments for the new module. This produces the list of active Bug Squad members for a release period.
  13. Add package to joomlacode.org
    1. Before the release is public, set the JoomlaCode package flags as follows: Visible=No, Public=No, Require Login=Yes.
    2. Set the Release flags as follows: Visible=Yes, Released=Yes.
    3. Once package is released, change the Package flags to Visible=Yes, Public=Yes, Require Login=No.
    4. Change the prior version package to Visible=No but leave the prior version release flags as they are.
  14. Update XML file on site for the new version number information.
    1. FTP connect to update1.joomla.org and Navigate to www/core
    2. All releases
      1. Change version attribute in list.xml (don't add new line except when incrementing major/minor version numbers)
    3. LTS Release
      1. Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension.xml
    4. STS Release
      1. Navigate to www/core/sts
      2. Change version attribute in list_sts.xml (don't add new line except when incrementing major/minor version numbers)
      3. Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension_sts.xml
    5. Test auto update from prior version(s) (make sure XML files have been copied to the SDN on update.joomla.org first)
      1. All releases
        1. Navigate to www/core/test
        2. Change version attribute in list_test.xml (don't add new line except when incrementing major/minor version numbers)
      2. LTS
        1. Upload patch package to this folder
        2. Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension_test.xml
      3. STS
        1. Navigate to www/core/teststs
        2. Upload patch package to this folder
        3. Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension_sts.xml
  15. Update Joomla.org Download article
  16. Publish security articles on developer site.
  17. Publish release announcement on Joomla.org
  18. Publish announcement on the forum
  19. Update download page
  20. Update Wiki: FAQ, Version history
  21. Email OSM list
  22. Create the Web Platform Installer packs and submit them

Post-release & Finalization phase[edit]

  1. Merge release branch to series development head (2.5 -> 2.5.x branch, 3.x -> master branch)
  2. Push release changes from local to remote Github repo
    1. Security fixes (if any)
    2. Version tag
    3. Version changes (SQL files, version.php, joomla.xml)
    4. Install checks
  3. Update Github repo for new version development
    1. Remove install checks
    2. Update version in version.php, joomla.xml, SQL files, SQL update files
  4. Delete old release branch after confirming all commits are merged to series development head
  5. Close security issues in security tracker

Pages to update[edit]

  1. Global:

Sites to update[edit]

  1. PLT Owned sites

Calculating Release Statistics[edit]

Using JoomlaCode and CHANGELOG[edit]

  1. Extract *all* issues from Tracker into spreadsheet. Make note of the date of the last release and the number of active issues at the time of the last release.
  2. Set a filter on the "Closed Date" column to be "after" "the day of the last release".
    • Calculate "Closed" count by aggregating status values for Closed, Duplicate Report, Known Issue, Not a bug, Not Joomla! Core, Unable to Confirm.
    • Calculate "Fixed in SVN" count by aggregating status values for Open and Information Required. (Note: this value is presented two times in the report.)
  3. Set a filter on the "Closed Date" column to be blanks:
    • Calculate "Open" count by aggregating status values for "Open" and "Information Required."
    • Calculate "Confirmed" count by aggregating status values for "Confirmed" and "In Progress."
    • Calculate "Pending" count by aggregating status values for "Pending" and "Ready to Commit."
  4. Calculate the "New Active Issues" by aggregating the "Open", "Confirmed" and "Pending" counts.
  5. Calculate the "net increase/decrease" by subtracting the "Last Release Active Issues" from the "New Active Issues."
  6. Count the "number of commits" by reviewing the CHANGELOG.php file and counting the documented commits.

Using GitHub[edit]

  1. Go to https://github.com/joomla/joomla-cms/compare/<version>...master where <version> is the previous release, this is GitHub's comparison view and will give stats from the previous release tag to the currently published master
  2. From this page, you can compile the number of commits, contributors, and files changed during the release period

Download Statistics[edit]

  1. Go to http://joomlacode.org/gf/project/joomla/frs/?action=FrsReport
  2. In the filter bar, set the start date to the date of the previous release and the end date to the day before the new release
  3. The "Downloads By Package" chart is the total number of downloads for each release (i.e. 2.5.16 and 3.2.0) and includes an "Other" piece for all older version downloads
  4. The "Downloads By Release" chart separates the packages by new install and updates

Alternative Method for Stats[edit]

  • Fixed in SVN: Create query with close date > date of prior release and status = Fixed in SVN.
  • Commits: Count from CHANGELOG.php as indicated above.
  • New Reports: Run query with all status codes and open date > date of prior release.
  • Increase / decrease in active issues: See note below
  • Closed: Run query with closed date > date of prior release and status code one of Closed, Duplicate Report, Known Issue, Not a bug, Not Joomla! Core, Unable to Confirm.
  • Open at time of release: query of all issues with status = Open or Information Required
  • Confirmed at time of release: query of all issues with status = Confirmed or In Progress
  • Pending at time of release: query of all issues with status = Pending or Ready to Commit

Increase/Decrease in Active Issues[edit]

  • Total active issues now = Open at time of release + Confirmed at time of release + Pending at time of release
  • This number minus the total active as of prior release is the net increase or decrease

As a check, make sure the following formula works:

  • Prior release total active issues + New Reports - (Closed + Fixed in SVN) should equal the Total Active Issues now.