Alexander Makarov
10 years ago
4 changed files with 145 additions and 117 deletions
@ -0,0 +1,15 @@
|
||||
Автоматизація |
||||
============= |
||||
|
||||
Є кілька задач, які можна автоматизувати працюючи з Yii: |
||||
|
||||
- Створення мапи класів `classes.php` у кореневій директорії фреймворку. |
||||
Виконати `./build/build classmap` для її створення. |
||||
|
||||
- Створення анотацій `@property` у файлах класів, що описують властивості представлені функціями для отримання (getters) та призначення (setters) властивостей. |
||||
Виконати `./build/build php-doc/property` для їх оновлення. |
||||
|
||||
- Виправлення стилю кодування та інших невеличких проблем у коментарях phpdoc. |
||||
Виконати `./build/build php-doc/fix` для виправлення. |
||||
Перед тим як створювати коміт, необхідно перевіряти зміни, оскільки команда не є досконалою й можливі не бажані зміни. |
||||
Можна використовувати `git add -p` для перегляду змін. |
||||
@ -1,36 +1,49 @@
|
||||
Yii version numbering |
||||
===================== |
||||
Версіонування Yii |
||||
================= |
||||
|
||||
Релізи |
||||
------ |
||||
Цей документ описує політику призначення версій Yii. Поточна стратегія призначення версій |
||||
базується на [ferver](https://github.com/jonathanong/ferver), це за думкою розробників є більш практичним |
||||
та розумним рішенням, ніж використання [semver](http://semver.org/) (див. [#7408](https://github.com/yiisoft/yii2/issues/7408) для довідки). |
||||
|
||||
A.B.C |
||||
У колі головних розробників неодноразово підкреслювалась важливість зберігати зворотну сумісність релізів 2.0.x на 100%. |
||||
Але це ідеалістичний план. Стаття про ferver доводить, що досягнути цього на практиці дуже важко, |
||||
не зважаючи на те, використовується semver чи ні. |
||||
|
||||
A = Для Yii2 це завжди 2. |
||||
B = Основна версія. Не-BC (`BC`, від англ. Backward compatibility - зворотна сумісність) зміни із інструкціями щодо оновлення. |
||||
C = BC зміни та доповнення. |
||||
Загалом, політика призначення версій наступна: |
||||
|
||||
Реліз-кандидати |
||||
--------------- |
||||
## Патч-релізи `2.x.Y` |
||||
|
||||
A.B.C-rc |
||||
A.B.C-rc2 |
||||
Патч-релізи, які мають бути на 100% зворотно сумісними. В ідеалі, вони містять лише виправлення помилок, що зменшує |
||||
можливість порушення зворотної сумісності. На практиці, релізи починаючи з 2.0.x стали частішими та зазвичай містять невеликі доповнення, |
||||
що дає можливість користувачам почати використовувати ці зміни раніше. |
||||
|
||||
Це коли ми хочемо зробити реліз-кандидат. Номер RC збільшується доки ми не отримаємо стабільний реліз без будь-яких |
||||
критичних помилок і звітів про звортню несумісність. |
||||
* Підтримуються у гілці `2.x` |
||||
* Переважно містять виправлення помилок та невеликі покращення |
||||
* Відсутні великі зміни та доповнення |
||||
* 100%-ва зворотна сумісність, що гарантує оновлення без проблем. Виключенням можуть бути лише проблеми безпеки, які потребують порушення зворотної сумісності |
||||
* Цикл релізу близько 1-2 місяців |
||||
* Не має необхідності у пре-релізах (альфа, бета, реліз-кандидат) |
||||
* Регулярно об'єднуються з головною (майстер) гілкою (щонайменш раз у тиждень вручну) |
||||
|
||||
Альфи та бети |
||||
------------- |
||||
|
||||
A.B.C-alpha |
||||
A.B.C-alpha2 |
||||
## Молодші (майнор) релізи `2.X.0` |
||||
|
||||
Альфи це є нестабільні версії, де значні помилки можуть і, ймовірно, дійсно будуть. |
||||
API ще фіксується і може бути суттєво змінений. |
||||
`alpha2` і т.д. можуть або не можуть бути випущені на основі загальної стабільності коду та API. |
||||
Зворотно несумісні релізи, що містять великі доповнення та зміни, які можуть порушувати зворотну сумісність. Оновлення з ранніх версій |
||||
може бути не простим, але у наявності повна інструкція по оновленню або навіть скрипт. |
||||
|
||||
A.B.C-beta |
||||
A.B.C-beta2 |
||||
* Розроблюються у головній (майстер) гілці |
||||
* Переважно містять нові доповнення та виправлення помилок |
||||
* Містять невеликі доповнення та виправлення помилок з патч-релізів |
||||
* Можуть мати зворотно несумісні зміни, які записуються у файл `UPGRADE-2.X.md` |
||||
* Цикл релізу близько 6-8 місяців |
||||
* Необхідні пре-релізи: `2.X.0-alpha`, `2.X.0-beta`, `2.X.0-rc` |
||||
* Потребують маркетингових зусиль та публікування у головних новинах |
||||
|
||||
Бета більш-менш стабільна із меншою кількістю помилок та меншою нестабільністю API, ніж альфа. |
||||
Там все ще можуть бути зміни в API, але на це повинна бути вагома причина. |
||||
|
||||
## Головні (мажор) релізи `X.0.0` |
||||
|
||||
Це наче 2.0 після 1.0. Такий перехід, вірогідніше, буде не частіше ніж кожні 3-5 років, у зв'язку з просуванням сторонніх технологій |
||||
(наприклад, оновлення PHP з 5.0 до 5.4). |
||||
|
||||
> Примітка: Офіційні розширення використовують таку ж саму політику призначення версій але можуть публікуватись незалежно від |
||||
фреймворку, тобто номера версій фреймворку та розширення не повинні обов'язково збігатсь. |
||||
|
||||
Loading…
Reference in new issue