Through this strategy document, you can set out what the community of Joomla users from simple & ordinary non-technical users to high-level technical developers. You can expect from the products that come under the umbrella of the Joomla project.
This strategy is completely about how a company is approaching and managing change: how they are adapting and growing their products in an ever-changing technological landscape. It is all about how you should communicate to your users and contributors what to expect from their products as they can change from one release to the next and how they are guiding to their contributors towards making the future changes.
In the project, the stakeholders have broadly untrustworthy needs and a balance must be hit among those for whom any change is unwelcome and all shades to the other extreme of those who prosper is unwelcome and all shades to the other extreme of those, who thrive on constant change.
Change is much important if the product is to remain relevant to the intended users, so the main goal is to manage the change in such a way that disruption must be minimized that it can cause. This strategy is mainly written to be as general as possible and to enable new products to be added to the portfolio without forcing any extensive re-writes.
However, this strategy builds on the extensive practical experience of various people over the years since the project’s foundation. The logic behind all this is written here, and the lesion learned in leading up to it is exterior to the scope of the document itself, and reference must be made to other sources for that comments.
1.1 Executive Summary: Essentially, this document is quite long because there is a lot of detail that requires to be covered that means there are lots of people, who will not read all of it. This section mainly summarizes what you need to know and point you to the suitable sections for extra information.
Below, you can find important points of this strategy:
The version numbering scheme is the main key to understand the amount of change innate in a release. The version number is in three different parts separated by dots: [major].[minor].[patch]. For instance, 2.5.18 has a major number of 2, a minor number of 5 and a patch number of 18. A release that increases the main number is considered as a major release. One that increases only with minor number is a minor release and one that increase the patch number is the patch release.
One important release is the only one type of release, where backward compatibility can be broken deliberately. Only a minor release can add some features and abilities, but it is essential to be backward compatible with the release it replaces. However, patch releases are for bug and security fixes only and will not break backward compatibility.
Inside every major series, only the most recent minor release is supported. When a new minor release is made, support for the earlier minor release is ended.
The best thing about Joomla is that they are taking security as main point, so they have special team for it, who are known for reviewing all reported problems and take the important action to lessen each confirmed problem. For further information, you can refer to security policy.
The main aim is to deliver a highly flexible for digital publishing and collaboration.
- The goal is to offer a steady and flexible platform for current and future user base.
- To make innovation obtainable for users and developers on a manageable basis.
- Making it a lot easier for developers to add code to the project at any time.
Moreover, Joomal is also trying to follow the slogan “power through simplicity” for all its developments. For this, the company has five very important principles inbuilt to the Joomla development strategy intended at achieving our goals:
1.4.1 Stable Master Branches: It is very much important to the main aim that the master branch of each important version of a Joomla product is constant.
1.4.2 Predictable & Incremental software releases: This is supported by our Release Policy and Support Policy.
1.4.3 Strong backward compatibility support: For any software platform, Backward compatibility is a high priority. It is mainly supported by Backward Compatibility Policy and our Upgrade Policy.
1.4.4 Sound security policy: This is supported by our Security Policy.
2. Contributor Ploicy
Below mentioned is the summary of the least requirements that must be met for code contributions to be considered for addition to a Joomla product.
- 2.1 Coding standards: All code submitted for amalgamation must obey with the latest Coding Standards.
- 2.2 Automated tests: For separating parts or features of the software, Automated tests are used and making sure that they perform accurately. Before new code can be combined, all existing tests must be passed.
- 2.3 Additional tests for all new API classes and methods
- 2.4 Documentation for all changes and additions to the code base
- 2.5 Additional requirements for specific Joomla products
3. Release Policy
The release policy explains how every release fits into an overall release life-cycle and describes the goals that it must be reached while life-cycle.
3.1 Software releases life-cycle
- 3.1.1 Planning phase
- 3.1.2 Development and testing phase
- 3.1.3 Release Phase
3.2 Software milestones
- 3.2.1 Alpha
- 3.2.2 Beta
- 3.2.3 Release Candidate (RC)
- 3.2.4 General Availability (GA)
3.3. Version Numbering
4. Support Policy
Joomla project officially distributes is subject to this support policy that sets out what you can expect in a way of bug and security fixes. Only the latest and updated minor release within a major series is supported. With no further minor release, the code may be declared end-of-life and therefore, unsupported.
4.1 Issue severity
4.2 Support definition
4.3 Supported releases
- 4.3.1 Predictable EOL (end-of-life) for major versions
- 4.3.2 Estimated EOL (end-of-life) for major versions
- 4.3.3 Announcement of EOL (end-of-life) for major version
- 4.3.4 Patch releases for a minor version
- 4.3.5 Examples
5. Upgrade Policy
This is one such policy that does not go for the Joomla framework. The main aim of upgrading from one version of a product to any subsequent version will always remain similar like as simple and painless as possible. Since, it is not originally possible to support direct upgrades from one random version to any other random version; this policy sets out the minimal upgrade path that will be supported.
When there are important backward-compatibility breaks, there is an upgrade that becomes a migration either in the code, the data or the underlying platform. Rather than this, a new website must be installed probably on a more up-to-date platform. Across to the newer website, configuration information and possibly some software is copied with any needed transformations applied.
- 5.1 Patch releases
- 5.2 Minor releases
- 5.3 Major releases
- 5.4 Example upgrade/migration path
6. Backward Compatibility Policy
The Joomla project mainly looks to maintain backward compatibility and full backward compatibility can be expected within a major series. Whenever a new major series is started backward compatibility may only be broken. Easy & clean maintainable code is highly important, but as time progresses the requirement to maintain backward compatibility makes software more difficulty and least maintainable. In the first release of a new major series, this technical debt can only be relieved.
- 6.1.1 PHP
- 6.1.3 Database schemata
- 6.1.4 XML schemata
- 6.1.5 JSON schemata
- 6.1.6 Language keys
- 6.1.7 Rendered markup
- 6.1.8 URLs
6.4 Minimum technical requirements