Обслуговування

Протягом життя молодшої версії нові релізи (патчі) публікуються щомісяця. Цей документ описує межі допустимих змін.

Виправлення багів приймаються за наступних умов:

• Зміна не порушує валідні модульні тести;
• Нові модульні тести покривають виправлення бага;
• Поточна поведінка бага не є широко використовуваною як "функція".

Щоб уникнути порушення зворотної сумісності, ми, як правило, дуже суворо ставимося до змін, які приймаються до версій патчів.

Окрім виправлень багів, інші незначні зміни можуть бути прийняті до версії патчу
у кожному конкретному випадку:

• Новіші версії PHP: Виправлення, які додають підтримку новіших версій PHP прийнятні, якщо вони не порушують набір модульних тестів, але ми ніколи не додаємо
  підтримку новіших функцій PHP;
• Новіші версії популярних ОС: Виправлення, які додають підтримку новіших версій популярних ОС (Linux, MacOS і Windows) є прийнятними, якщо вони не порушують набір модульних тестів, але ми ніколи не додаємо підтримку новіших функцій PHP або новіших версій ОС;
• Переклади: Оновлення та доповнення перекладів завжди зливаються в найстарішу підтримувану гілку;
• Зовнішні дані: Оновлення для зовнішніх даних, включених до Symfony, можуть бути оновлені (як, наприклад, ICU);
• Оновлення версій для залежностей Composer: Зміна мінімальної версії залежності можлива, підвищення до старшої або збільшення мінімальної версії PHP - ні;
• Тести: Можна додавати тести, які збільшують покриття коду.

Наступні зміни зазвичай не приймаються у версії патча, за винятком окремих випадків, які розглядаються поодинці (здебільшого, коли це пов'язано з виправленням проблеми безпеки):

• Покращення продуктивності: Покращення продуктивності слід приймати лише якщо зміни є локальними (розташовані в одному класі) і тільки для алгоритмічних проблем (будь-які такі патчі повинні супроводжуватися цифрами, які показують значне покращення реального коду);
• Стандарт кодування та рефакторинг: Виправлення стандарту кодування або рефакторинг коду майже ніколи не приймаються, за винятком узгодженості з існуючою базою коду, якщо вони не є надто інвазивними, і якщо їх злиття у вищі гілки не призведе до складного злиття гілок.
• Додавання нових класів або не приватних методів: Під час роботи над виправленням багу, ніколи не створюйте нових класів або публічних/захищених методів (або глобальних
  функції).
• Додавання опцій конфігурації: Додавання нових опцій конфігурації ніколи не дозволяється.
• Додавання нових застарілостей: Після досягнення стабільності версії, нові застарілості більше не можна додавати.
• Додавання або оновлення анотацій: Додавання або оновлення анотацій (наприклад, анотацій PHPDoc) заборонено; їх виправлення може бути дозволено.

Все, що явно не перераховано вище, має бути зроблено у наступній молодшій або старшій
версії. Наприклад, наступні зміни ніколи не приймаються у версії патча:

• Нові функції;
• Посилення безпеки;
• Розриви зворотної сумісності: Зауважте, що порушення зворотної сумісності можуть бути зроблені під час виправлення проблеми безпеки, якщо її неможливо виправити іншим способом;
• Підтримка зовнішніх платформ: Додавання підтримки нових платформ (таких як Google App Engine) не може бути зроблена у версіях патчів;
• Повідомлення про виключення: Повідомлення про виключення не можна змінювати,
  оскільки деякі автоматизовані системи можуть покладатися на них (навіть якщо це не рекомендується);
• Додавання нових залежностей Composer;
• Підтримка нових старших версій залежностей Composer: Врахування підтримки новіших версій існуючої залежності не
  є неприйнятним.
• Веб-дизайн: Зміна веб-дизайну вбудованих сторінок, таких як виключення, панелі інструментів або профілювальника не дозволяється.