Joomla! Documentation™

Background

As of version 1.7.0 released July 2011, the Joomla CMS and the Joomla Platform are separate projects. The CMS is now a user or customer of the Platform (libraries/joomla). This means that we need to change the way we work on issues that require changes to the Platform. Please note that this is an on-going process that is subject to revision as we gain more experience with the two projects.

Some issues affect only the CMS or only the platform. Other issues affect both projects. Each type of issue is discussed below.

CMS Issues That Don't Touch the Platform

If CMS only, there is no change to the current process. Everything will work through the Joomlacode CMS Issue Tracker.

Platform Issues That Don't Cause CMS Bugs

Some platform bugs do not directly affect the CMS. An example might be a bug in a method that is not used in the CMS. In this case, the issue should be tracked and fixed in the Platform Github site.

• If a patch is available, issue a pull request to Github. This process will automatically create a Github tracker issue.
• If no patch is available, create a Github tracker issue.
• If an issue has been reported in the CMS tracker, close the issue in the CMS tracker and create an issue in the Platform tracker. If it is convenient, you can link back to the CMS tracker item for details.

Issues That Affect CMS and Platform

If an issue is in a file in the libraries/joomla folder and is causing an issue in the CMS, we will track and fix the issue in the CMS and then report the issue to the Platform project, as follows:

• Create an issue in the CMS tracker, assigned to the Platform category.
• Using the normal Bug Squad process, patch and test the issue and set to Ready to Commit status.
• When committed, the person committing the change will create a Github pull request or github tracker issue to notify the platform of the bug fix. The Github tracker issue can simply reference back to the CMS tracker item.
  • Name the pull request Joomla CMS [#12345] Tracker description goes here.
• Wherever possible, unit tests should be included with the pull request.
  • If existing code has existing unit tests, the unit tests need to be updated to reflect the code changes.
  • If existing code does not currently have unit tests, new unit tests will be greatly appreciated.
  • If new code is being added, it needs to include unit tests.

What If The Platform Refuses a Patch

In some cases (hopefully rare), the platform project may not want to apply a proposed patch that has been applied in the CMS. In this case, the issue should be escalated so a decision can be made. Possible resolutions include:

• Accept the CMS patch as is
• Accept a modified version of the CMS patch
• Fix the issue with a different approach and patch (in which case this can be changed also in the CMS)
• Fix the issue only in the CMS (for example, libraries/CMS) instead of the platform.

New CMS Features With Platform Changes

In some cases, new CMS features will require platform changes as well as other CMS changes. In this case, there are two possible approaches, as follows:

Option A

Break the project into two phases, with the first phase being the platform changes and the second phase being the CMS changes.

• Treat the first phase of the project as a platform-only feature and add it to the platform.
• Treat the second phase as a CMS-only feature and add it to the CMS (perhaps in a branch with the latest platform version loaded).
• Merge the change into the CMS after the platform version has been updated to the version that contains the phase I work.

Option B

Once the CMS has its own Github repository, it will be possible to set up a project so that has the CMS code pointing to the CMS repository on Github and the Platform code pointing to the Platform repository on Github. When the feature is completed and ready to merge back, you can create separate pull requests, one for each repository. Note that you will still need to make sure the correct Platform version is available to the CMS.