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.
1.2 Mission:
The main aim is to
deliver a highly flexible for digital publishing and collaboration.
1.3 Goals:
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.
1.4 Principles:
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.2 Software
milestones
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.
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 Applicability
6.1.1 PHP
6.1.2 JavaScript
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.2 Deprecation
6.3 Regressions
6.4 Minimum technical
requirements
6.5 Downgrading
