Skip to content

Commit d941db8

Browse files
committed
minor #15129 Update bc.rst (94noni)
This PR was merged into the 4.4 branch. Discussion ---------- Update bc.rst To map number version from https://symfony.com/doc/current/contributing/community/releases.html#backward-compatibility Also i think mentioning those internal deprecation messages can be useful here in this doc section. <!-- If your pull request fixes a BUG, use the oldest maintained branch that contains the bug (see https://symfony.com/releases for the list of maintained branches). If your pull request documents a NEW FEATURE, use the same Symfony branch where the feature was introduced (and `5.x` for features of unreleased versions). --> Commits ------- 6e3a415 Update bc.rst
2 parents 85c9813 + 6e3a415 commit d941db8

File tree

1 file changed

+6
-3
lines changed

1 file changed

+6
-3
lines changed

contributing/code/bc.rst

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4,10 +4,13 @@ Our Backward Compatibility Promise
44
Ensuring smooth upgrades of your projects is our first priority. That's why
55
we promise you backward compatibility (BC) for all minor Symfony releases.
66
You probably recognize this strategy as `Semantic Versioning`_. In short,
7-
Semantic Versioning means that only major releases (such as 2.0, 3.0 etc.) are
8-
allowed to break backward compatibility. Minor releases (such as 2.5, 2.6 etc.)
7+
Semantic Versioning means that only major releases (such as 5.0, 6.0 etc.) are
8+
allowed to break backward compatibility. Minor releases (such as 5.1, 5.2 etc.)
99
may introduce new features, but must do so without breaking the existing API of
10-
that release branch (2.x in the previous example).
10+
that release branch (5.x in the previous example).
11+
12+
We also provide deprecation message triggered in the code base to help you with
13+
the migration process across major release.
1114

1215
.. caution::
1316

0 commit comments

Comments
 (0)