| | 1 | = Выпуск релиза = |
| | 2 | |
| | 3 | Выпуск конечной версии продукта всегда сопряжен с рядом сложностей поэтому к нему нужно подходить |
| | 4 | последовательно не забывая ничего важного. |
| | 5 | |
| | 6 | В разработке конечного продукта принимают участие не только разработчки, |
| | 7 | но и локализаторы и тестеры, поэтому нужно организовать их работу таким образом |
| | 8 | чтобы использовать ресурсы наиболее рационально. |
| | 9 | |
| | 10 | На данный момент подготовка к выпуску релиза включает в себя |
| | 11 | выпуск пререлизов (pre) и собственно релиза. |
| | 12 | |
| | 13 | Все крупные изменения и улучшения вносятся до выпуска первого пререлиза. |
| | 14 | После этого строки должны быть заморожены для того чтобы локализаторы |
| | 15 | могли приступить к работе и не выполнять её несколько раз. |
| | 16 | |
| | 17 | Также пререлиз должен быть готов к тестированию пользователями |
| | 18 | добровольцами, поэтому для них мы должны подготовить следующую информацию: |
| | 19 | * NEWS файл c описанием изменений |
| | 20 | * архивы с исходными кодами и, возможно, версии пакетов для некоторых дистрибутивов (должны быть доступны в [http://www.midnight-commander.org/downloads downloads]) |
| | 21 | * Обновить документацию (*.hlp, man-page, имеющуюся wiki документацию) чтобы тестеры не рапортовали об изменившемся поведении, как об ошибках (приоритет следует отдавать английскому языку). |
| | 22 | * Подготовить публичный анонс для размещения на новостных сайтах. |
| | 23 | |
| | 24 | После пререлиза должна последовать волна баг-репортов, по мере |
| | 25 | закрытия которых можно выпускать следующие пререлизы. |
| | 26 | В конечном счёте один из них станет релизом (когда все критические ошибки, |
| | 27 | мешающие релизу, будут устранены). |
