| layout | group | subgroup | title | menu_title | menu_order | level3_menu_node | level3_subgroup | version | github_link |
|---|---|---|---|---|---|---|---|---|---|
default |
arch-guide |
Architectural Basics |
Versioning policy overview |
Versioning policy overview |
2 |
level3child |
versioning |
2.0 |
architecture/versioning_overview.md |
Magento uses software versioning to identify the compatibility of changes in the public code. By comparing two versions of the same component, you can tell whether it has any backward-incompatible changes in the public API or other significant code changes.
Versioning also helps:
-
track software dependencies. Managing dependencies can be a challenging task in a large, generously populated software environment like Magento, which ships with more than 100 core modules.
-
support compatibility verification and ease troubleshooting. Well known and tested combinations of Magento 2.x platform modules can reduce the number of combinations that require testing in your installation.
Source code is considered part of the public API only if it is explicitly marked by the @api docblock tag. This designation indicates that the code can be used or customized by other components, such as formal interfaces and dependency injection points.
Do not mark private code with @api or changes to this private interface will trigger a version change.
For PHP code, compatibility of @api can be tracked on the level of structural elements (such as class signatures, interfaces, or methods). For other source code, compatibility is tracked only on the file level (for example, the file has been deleted or renamed).
Where is version information stored?