Actions

Difference between revisions of "Issues that affect both the CMS and Platform"

From Joomla! Documentation

(initial work)
 
(revisions)
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
{{inuse}}
+
===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.
+
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.''
  
First of all, many features only affect one
+
Some issues affect only the CMS or only the platform. Other issues affect both projects. Each type of issue is discussed below.
  
1. lots of features only touch one or other
+
===CMS Issues That Don't Touch the Platform===
1. if cms only, no change to the process
+
If CMS only, there is no change to the current process. Everything will work through the Joomlacode CMS Issue Tracker.
2. if platform only, pull request to github (creates tracker automatically)
+
 
3. if a bug fix touches both places:
+
===Platform Issues That Don't Cause CMS Bugs===
1. add it to the cms feature or issue tracker
+
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.
2. normal jbs process  
+
* If a patch is available, issue a pull request to Github. This process will automatically create a Github tracker issue.
3. when committed, committer will create a github pull request or github tracker issue to notify the platform of the bug fix
+
* If no patch is available, create a Github tracker issue.
1. could create a unit test to test the fix
+
* 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.
4. if a feature touches both places:
+
 
1. option a
+
===Issues That Affect CMS and Platform===
1. do platform changes first
+
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:
2. then add cms changes through normal channels
+
* Create an issue in the CMS tracker, assigned to the Platform category.
2. plan b
+
* Using the normal Bug Squad process, patch and test the issue and set to Ready to Commit status.
1. can set up project so that has the cms pointing to the cms repo and the platform pointing to the platform repo. Can create separate pull requests when feature is done.
+
* 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 <code>Joomla CMS [#12345] Tracker description goes here</code>.
 +
* 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.
 +
 
 +
[[Category:Bug Squad]] [[Category:Development]]
 +
 
 +
===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.

Latest revision as of 17:34, 24 August 2011

Contents

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.