Release cycle uk UA

Цикл релізу

ASF uses common C# versioning with 4 numbers, written as A.B.C.D. В цій версії завжди заморожена, вказуючи на фіксований вихідний код, який він був побудований (зібраний разом з випуском). Ми не маємо наміру видаляти будь-яку попередньо опубліковану версію, доки наш хостинг-провайдер (GitHub) залишається нормальним зі збереженням їх на невизначене майбутнє, таким чином ви можете безпечно відкотитися до будь-якої з них без потреби створення самоскопії.

In general in terms of ASF versioning, we're doing our best to follow semver versioning of MAJOR.MINOR.PATCH on the 3 least significant numbers - B.C.D. Ці три числа прямо пов'язані з кодом ASF. The most significant A number indicates changes with a scope that goes beyond ASF codebase itself, usually directly affecting the foundation of the program.

ASF as a project is aiming to have more or less one feature release per month, indicated by a bump of C number. In order to make such release possible, we have smaller pre-releases dedicated to advanced users, which serve as smaller milestones of changes that are released on as-needed basis when there will be enough of changes since the last pre-release to focus on. Врешті-решт, коли остаточний пре-випуск буде визначений як стабільний і зрілий, без відомих критичних регресій, які слід виправити в порівнянні з попередньою стабільною версією, Вона буде підвищена до нового стабільного релізу, водночас відкриття нового місячного циклу для наступного.

В той час як ми робимо все можливе, щоб навіть наші пре-релізи були відносно стабільними, слід зазначити, що пре-релізи повинні бути ретельно оцінені при виконанні будь-якого виробничого середовища. Пре-релізи можуть мати критичних помилок і інакше зламану функціональність, що саме тому ми випускаємо їх на початку - щоб уникнути цього безладу в наших стабільних вибудовах і запропонувати надійне програмне забезпечення. Якщо ви не хочете приймати збільшений ризик, це пов'язане з використанням потенційно нестабільного програмного забезпечення, , будь ласка, уникайте використання пре-реліз збірки і дотримуйтесь наших останньої стабільної побудувати замість цього, що є більш доречним для більшості користувачів.

Залежно від кількості змін у циклі, зазвичай існує один C очки версій (від попередньої стабільної), і D відбиває кожен пре-реліз на потрібній основі. However, when introducing changes with far bigger scope, especially breaking changes, the cycle might start from (or switch in the middle to) B or even A bump - such switch indicates that current release cycle has a potential to be more unstable than usual, and should be tested carefully. Keep in mind that semver changes we're making relate only to previously released stable version, we do not track versioning across pre-releases in a cycle themselves, which means that version 1.0.1.2 might have a new feature that 1.0.1.1 didn't have, as long as the previously marked stable release is from 1.0.0.X family. Крім того, можуть бути великі зміни навіть через два пре-релізи з одного циклу, що особливо вірно, коли ми досі вирішуємо остаточну форму новоствореної функціональності чи подібного.

Версійний бамп	Semver	Приклад змін
Ля		Основні зміни на рівні .NET runtime фундаменту, розбивши зміни, що знаходяться поза кодовою базою ASF, те, що може з'їсти вашого кота
Сі	Майор	Незначним часом роботи .NET змінюється, порушуючи зміни в кодовій базі, головним кодом редагування, що виходять за рамки другої класифікації
До	Мінор	Нові щомісячні цикли, зазвичай введення нових функцій, команд, властивостей конфігурації та інших змін, які не порушують існуючі налаштування
Ре	Патч	Нові пре-релізи, які є частиною існуючого циклу (зазначені більш значним числом), критичні виправлення помилок в існуючих стабільних релізах, що не вносять змін коду за межами необхідних

Будь ласка, зверніть увагу, що нещодавно введені функції і зміни можуть бути недокументовані (наприклад, на wiki) допоки через деякий час, так як документація зазвичай і записується як тільки остаточний код даної функції буде готовий (щоб зберегти нас щоразу перезапису документації, при її вирішенні - змінювати функцію, над якою ми працюємо). Через те, що пре-релізи можуть містити код в процесі виконання, який ще не має кінцевої форми, документація може з'явитися на пізнішому етапі розвитку. Те ж саме стосується загального список змін, який може бути недоступний для заданого попереднього релізу до деякий час пізніше. Therefore if you decide to use pre-releases then be prepared for looking inside ASF commits from time to time. Of course, lack of documentation applies only to pre-releases - each stable version must always have a complete changelog and documentation on the wiki the moment it's being released.

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

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