10000 Merge branch '2.7' into 2.8 · symfony/symfony-docs@1e63c9e · GitHub
[go: up one dir, main page]
Skip to content

Commit 1e63c9e

Browse files
wouterjwouterj
committed
Merge branch '2.7' into 2.8
2 parents d2958ad + b8c71bc commit 1e63c9e

File tree

10 files changed

+102
-11
lines changed

10 files changed

+102
-11
lines changed

‎book/validation.rst

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -516,9 +516,11 @@ For information on translating the constraint messages, see
516516
Constraint Targets
517517
------------------
518518

519-
Constraints can be applied to a class property (e.g. ``name``) or a public
520-
getter method (e.g. ``getFullName``). The first is the most common and easy
521-
to use, but the second allows you to specify more complex validation rules.
519+
Constraints can be applied to a class property (e.g. ``name``), a public
520+
getter method (e.g. ``getFullName``) or an entire class. Property constraints
521+
are the most common and easy to use. Getter constraints allow you to specify
522+
more complex validation rules. Finally, class constraints are intended
523+
for scenarios where you want to validate a class as a whole.
522524

523525
.. index::
524526
single: Validation; Property constraints

‎components/form/introduction.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -121,7 +121,7 @@ The following snippet adds CSRF protection to the form factory::
121121

122122
use Symfony\Component\Form\Forms;
123123
use Symfony\Component\HttpFoundation\Session\Session;
124-
use Symfony\Component\Security\Extension\Csrf\CsrfExtension;
124+
use Symfony\Component\Form\Extension\Csrf\CsrfExtension;
125125
use Symfony\Component\Security\Csrf\TokenStorage\SessionTokenStorage;
126126
use Symfony\Component\Security\Csrf\TokenGenerator\UriSafeTokenGenerator;
127127
use Symfony\Component\Security\Csrf\CsrfTokenManager;

‎components/serializer.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -169,7 +169,7 @@ The serializer can also be used to update an existing object::
169169
EOF;
170170

171171
$serializer->deserialize($data, 'Acme\Person', 'xml', array('object_to_populate' => $person));
172-
// $obj2 = Acme\Person(name: 'foo', age: '69', sportsman: true)
172+
// $person = Acme\Person(name: 'foo', age: '69', sportsman: true)
173173

174174
This is a common need when working with an ORM.
175175

‎contributing/code/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@ Contributing Code
66

77
bugs
88
patches
9+
maintenance
910
core_team
1011
security
1112
tests

‎contributing/code/maintenance.rst

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
Maintenance
2+
===========
3+
4+
During the lifetime of a minor version, new releases (patch versions) are
5+
published on a monthly basis. This document describes the boundaries of
6+
acceptable changes.
7+
8+
**Bug fixes** are accepted under the following conditions:
9+
10+
* The change does not break valid unit tests;
11+
* New unit tests cover the bug fix;
12+
* The current buggy behavior is not widely used as a "feature".
13+
14+
.. note::
15+
16+
When documentation (or phpdoc) is not in sync with the code, code behavior
17+
should always be considered as being the correct one.
18+
19+
Besides bug fixes, other minor changes can be accepted in a patch version:
20+
21+
* **Performance improvement**: Performance improvement should only be accepted
22+
if the changes are local (located in one class) and only for algorithmic
23+
issues (any such patches must come with numbers that show a significant
24+
improvement on real-world code);
25+
26+
* **Newer versions of PHP/HHVM**: Fixes that add support for newer versions of
27+
PHP or HHVM are acceptable if they don't break the unit test suite;
28+
29+
* **Newer versions of popular OSes**: Fixes that add support for newer versions
30+
of popular OSes (Linux, MacOS and Windows) are acceptable if they don't break
31+
the unit test suite;
32+
33+
* **Translations**: Translation updates and additions are accepted;
34+
35+
* **External data**: Updates for external data included in Symfony can be
36+
updated (like ICU for instance);
37+
38+
* **Version updates for Composer dependencies**: Changing the minimal version
39+
of a dependency is possible, bumping to a major one or increasing PHP
40+
minimal version is not;
41+
42+
* **Coding standard and refactoring**: Coding standard fixes or code
43+
refactoring are not recommended but can be accepted for consistency with the
44+
existing code base, if they are not too invasive, and if merging them on
45+
master would not lead to complex branch merging;
46+
47+
* **Tests**: Tests that increase the code coverage can be added.
48+
49+
Anything not explicitly listed above should be done on the next minor or major
50+
version instead (aka the *master* branch). For instance, the following changes
51+
are never accepted in a patch version:
52+
53+
* **New features**;
54+
55+
* **Backward compatibility breaks**: Note that backward compatibility breaks
56+
can be done when fixing a security issue if it would not be possible to fix
57+
it otherwise;
58+
59+
* **Support for external platforms**: Adding support for new platforms (like
60+
Google App Engine) cannot be done in patch versions;
61+
62+
* **Exception messages**: Exception messages must not be changed as some
63+
automated systems might rely on them (even if this is not recommended);
64+
65+
* **Adding new Composer dependencies**;
66+
67+
* **Support for newer major versions of Composer dependencies**: Taking into
68+
account support for newer versions of an existing dependency is not
69+
acceptable.
70+
71+
* **Web design**: Changing the web design of built-in pages like exceptions,
72+
the toolbar or the profiler is not allowed.
73+
74+
.. note::
75+
76+
This policy is designed to enable a continuous upgrade path that allows one
77+
to move forward with newest Symfony versions in the safest way. One should
78+
be able to move PHP versions, OS or Symfony versions almost independently.
79+
That's the reason why supporting the latest PHP versions or OS features is
80+
considered as bug fixes.

‎contributing/code/patches.rst

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -113,10 +113,12 @@ Choose the right Branch
113113
Before working on a patch, you must determine on which branch you need to
114114
work:
115115

116-
* ``2.3``, if you are fixing a bug for an existing feature (you may have
117-
to choose a higher branch if the feature you are fixing was introduced
118-
in a later version);
119-
* ``master``, if you are adding a new feature.
116+
* ``2.3``, if you are fixing a bug for an existing feature or want to make a
117+
change that falls into the :doc:`list of acceptable changes in patch versions
118+
</contributing/code/maintenance>` (you may have to choose a higher branch if
119+
the feature you are fixing was introduced in a later version);
120+
121+
* ``master``, if you are adding a new feature.
120122

121123
.. note::
122124

‎contributing/community/releases.rst

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -48,6 +48,11 @@ type of the release. This maintenance is divided into:
4848
be fixed. The end of this period is referenced as being the *end of life* of
4949
a release.
5050

51+
.. note::
52+
53+
The :doc:`maintenance document </contributing/code/maintenance>` describes
54+
the boundaries of acceptable changes during maintenance.
55+
5156
Symfony Versions
5257
----------------
5358

‎contributing/map.rst.inc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,7 @@
33
* :doc:`Bugs </contributing/code/bugs>`
44
* :doc:`Patches </contributing/code/patches>`
55
* :doc:`Reviewing Issues and Patches </contributing/community/reviews>`
6+
* :doc:`Maintenance </contributing/code/maintenance>`
67
* :doc:`The Core Team </contributing/code/core_team>`
78
* :doc:`Security </contributing/code/security>`
89
* :doc:`Tests </contributing/code/tests>`

‎cookbook/form/form_collections.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -297,7 +297,7 @@ new "tag" forms. To render it, make the following change to your template:
297297

298298
.. code-block:: html+twig
299299

300-
<ul class="tags" data-prototype="{{ form_widget(form.tags.vars.prototype)|e }}">
300+
<ul class="tags" data-prototype="{{ form_widget(form.tags.vars.prototype)|e('html_attr') }}">
301301
...
302302
</ul>
303303

‎cookbook/index.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,13 +22,13 @@ The Cookbook
2222
install/index
2323
logging/index
2424
profiler/index
25+
psr7
2526
request/index
2627
routing/index
2728
security/index
2829
serializer
2930
service_container/index
3031
session/index
31-
psr7
3232
symfony1
3333
templating/index
3434
testing/index

0 commit comments

Comments
 (0)
0