Internal links for development strategy

[mozaffar]

User description

Added: Internal links for development strategy page
Reformatted: Joomla! slogan

---

PR Type

Documentation

---

Description

• Added internal links to policy documents

• Reformatted Joomla! slogan with bold styling

---

Diagram Walkthrough

flowchart LR
  A["Development Strategy Page"] --> B["Backward Compatibility Policy"]
  A --> C["Support Policy"]
  A --> D["Upgrade Policy"]
  A --> E["Security Policy"]
  A --> F["Contributor Policy"]

Loading

File Walkthrough

	Relevant files
Documentation	index.md Internal links and slogan formatting                                          versioned_docs/version-5.3/development-strategy/index.md Added internal links to five policy documents Reformatted Joomla! slogan with bold markdown styling +6/-6

---

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Broken Link Risk Verify that the new internal links resolve correctly in the versioned docs context (anchors like /docs/... and hash fragments such as #support-phase often differ across versions or build outputs). * A release is said to be "backward compatible" with an earlier release if your system continues to work correctly when updated to that release even when other parts of your system were not updated at the same time. However, there are limits to what is covered by backward compatibility and you should read the [Backward Compatibility Policy](/docs/development-strategy/backward-compatibility-policy.md) for the full details. * A major release is the only kind of release where backward compatibility can be intentionally broken. A minor release may add new features and capabilities but it must be backward compatible with the release it replaces. Patch releases are for bug and security fixes only and will not break backward compatibility. A needed security fix can break backward compatibility of any kind of release. * Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](/docs/development-strategy/software-release-cycle.md/#support-phase) for further information. * Within each major series, only the most recent minor release is supported. As soon as a new minor release is made, support for the previous minor release ends. * A major series may be declared end-of-life (and hence become unsupported) only after at least 2 years have elapsed since the most recent minor release in that series. What this means is that each time a minor release is made it resets the support clock for that series, thus ensuring that a major series will enjoy extended life for as long as there is sufficient interest in producing minor releases for it. Patch releases do not reset the support clock. * There will always be a supported upgrade path from one version to any other subsequent version. By clearly defining what that upgrade path is, users can be more certain of a successful upgrade and developers will know exactly which upgrade paths must be tested. Refer to the [Upgrade Policy](/docs/development-strategy/software-release-cycle.md/#upgrades) for full details. * We take security very seriously and we have a special team, the JSST, who review all reported issues and take the necessary action to mitigate or fix each confirmed issue. Refer to [Security Policy](/docs/development-strategy/security-policy.md) for further information. * We welcome contributions, individual, collaborative or corporate, that will enhance our products for the benefit of the community. Refer to our [Contributor Policy](/about/contributing.md) for full details. Consistency Confirm the capitalization and bold styling of the slogan matches project-wide style guidance and existing occurrences across the docs to avoid inconsistency. Joomla tries to follow the slogan “**Power Through Simplicity**” for all its developments. For this, we have five major principles inherent to the Joomla development strategy aimed at achieving our goals:

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	✅ Remove .md from internal links Suggestion Impact: The commit removed .md from several internal links and switched to relative links, aligning with the suggestion (e.g., backward-compatibility-policy, software-release-cycle sections, security-policy). One link to /about/contributing kept the absolute path but removed .md. code diff: -* A release is said to be "backward compatible" with an earlier release if your system continues to work correctly when updated to that release even when other parts of your system were not updated at the same time. However, there are limits to what is covered by backward compatibility and you should read the [Backward Compatibility Policy](/docs/development-strategy/backward-compatibility-policy.md) for the full details. +* A release is said to be "backward compatible" with an earlier release if your system continues to work correctly when updated to that release even when other parts of your system were not updated at the same time. However, there are limits to what is covered by backward compatibility and you should read the [Backward Compatibility Policy](backward-compatibility-policy.md) for the full details. * A major release is the only kind of release where backward compatibility can be intentionally broken. A minor release may add new features and capabilities but it must be backward compatible with the release it replaces. Patch releases are for bug and security fixes only and will not break backward compatibility. A needed security fix can break backward compatibility of any kind of release. -* Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](/docs/development-strategy/software-release-cycle.md/#support-phase) for further information. +* Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](software-release-cycle.md/#support-phase) for further information. * Within each major series, only the most recent minor release is supported. As soon as a new minor release is made, support for the previous minor release ends. * A major series may be declared end-of-life (and hence become unsupported) only after at least 2 years have elapsed since the most recent minor release in that series. What this means is that each time a minor release is made it resets the support clock for that series, thus ensuring that a major series will enjoy extended life for as long as there is sufficient interest in producing minor releases for it. Patch releases do not reset the support clock. -* There will always be a supported upgrade path from one version to any other subsequent version. By clearly defining what that upgrade path is, users can be more certain of a successful upgrade and developers will know exactly which upgrade paths must be tested. Refer to the [Upgrade Policy](/docs/development-strategy/software-release-cycle.md/#upgrades) for full details. -* We take security very seriously and we have a special team, the JSST, who review all reported issues and take the necessary action to mitigate or fix each confirmed issue. Refer to [Security Policy](/docs/development-strategy/security-policy.md) for further information. -* We welcome contributions, individual, collaborative or corporate, that will enhance our products for the benefit of the community. Refer to our [Contributor Policy](/about/contributing.md) for full details. +* There will always be a supported upgrade path from one version to any other subsequent version. By clearly defining what that upgrade path is, users can be more certain of a successful upgrade and developers will know exactly which upgrade paths must be tested. Refer to the [Upgrade Policy](software-release-cycle.md/#upgrades) for full details. +* We take security very seriously and we have a special team, the JSST, who review all reported issues and take the necessary action to mitigate or fix each confirmed issue. Refer to [Security Policy](security-policy.md) for further information. +* We welcome contributions, individual, collaborative or corporate, that will enhance our products for the benefit of the community. Refer to our [Contributor Policy](/about/contributing) for full details. Use relative links without file extensions to avoid build-time 404s and to let Docusaurus resolve versioned docs correctly. Update the path to match the versioned doc route and remove ".md". versioned_docs/version-5.3/development-strategy/index.md [30] -* A release is said to be "backward compatible" with an earlier release if your system continues to work correctly when updated to that release even when other parts of your system were not updated at the same time. However, there are limits to what is covered by backward compatibility and you should read the [Backward Compatibility Policy](/docs/development-strategy/backward-compatibility-policy.md) for the full details. +* A release is said to be "backward compatible" with an earlier release if your system continues to work correctly when updated to that release even when other parts of your system were not updated at the same time. However, there are limits to what is covered by backward compatibility and you should read the [Backward Compatibility Policy](/docs/development-strategy/backward-compatibility-policy) for the full details. [Suggestion processed] Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that using extensionless links is a best practice for Docusaurus, improving link robustness and preventing potential build issues.	Low
	✅ Use extensionless link with anchor Suggestion Impact: The commit changed the Support Policy link by removing the leading /docs path and keeping a relative link with .md and anchor (software-release-cycle.md/#support-phase). While it did not fully adopt extensionless URLs, it modified the exact line and adjusted the link structure, reflecting partial implementation of the suggestion's intent to fix linking. Additionally, other links in the same section were altered similarly. code diff: -* Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](/docs/development-strategy/software-release-cycle.md/#support-phase) for further information. +* Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](software-release-cycle.md/#support-phase) for further information. * Within each major series, only the most recent minor release is supported. As soon as a new minor release is made, support for the previous minor release ends. * A major series may be declared end-of-life (and hence become unsupported) only after at least 2 years have elapsed since the most recent minor release in that series. What this means is that each time a minor release is made it resets the support clock for that series, thus ensuring that a major series will enjoy extended life for as long as there is sufficient interest in producing minor releases for it. Patch releases do not reset the support clock. -* There will always be a supported upgrade path from one version to any other subsequent version. By clearly defining what that upgrade path is, users can be more certain of a successful upgrade and developers will know exactly which upgrade paths must be tested. Refer to the [Upgrade Policy](/docs/development-strategy/software-release-cycle.md/#upgrades) for full details. -* We take security very seriously and we have a special team, the JSST, who review all reported issues and take the necessary action to mitigate or fix each confirmed issue. Refer to [Security Policy](/docs/development-strategy/security-policy.md) for further information. -* We welcome contributions, individual, collaborative or corporate, that will enhance our products for the benefit of the community. Refer to our [Contributor Policy](/about/contributing.md) for full details. +* There will always be a supported upgrade path from one version to any other subsequent version. By clearly defining what that upgrade path is, users can be more certain of a successful upgrade and developers will know exactly which upgrade paths must be tested. Refer to the [Upgrade Policy](software-release-cycle.md/#upgrades) for full details. +* We take security very seriously and we have a special team, the JSST, who review all reported issues and take the necessary action to mitigate or fix each confirmed issue. Refer to [Security Policy](security-policy.md) for further information. +* We welcome contributions, individual, collaborative or corporate, that will enhance our products for the benefit of the community. Refer to our [Contributor Policy](/about/contributing) for full details. Avoid hardcoding ".md" and ensure the anchor matches the generated slug. Use the clean route without extension so the hash fragment reliably resolves in production. versioned_docs/version-5.3/development-strategy/index.md [32] -* Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](/docs/development-strategy/software-release-cycle.md/#support-phase) for further information. +* Releases are either supported or they are not supported. When we say that a release is supported, we mean that all major issues and most minor issues will be addressed in a subsequent release. Refer to [Support Policy](/docs/development-strategy/software-release-cycle#support-phase) for further information. [Suggestion processed] Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that using extensionless links is a best practice for Docusaurus, which also applies to links with anchors, improving link robustness.	Low
Update

[HLeithner]

I think docusaurus has an issue with linking to headlines/anchors

• Broken link on source page path = /docs/development-strategy/:
  -> linking to software-release-cycle.md/#support-phase (resolved as: /docs/development-strategy/software-release-cycle.md/#support-phase)
  -> linking to software-release-cycle.md/#upgrades (resolved as: /docs/development-strategy/software-release-cycle.md/#upgrades)

I'm not sure if this is already fixed or if you need to remove the anchor links