Версия 4.6.0

# Соглашение по оформлению кода Java

Стиль форматирования (Eclipse: Window -> Preferences -> Java -> Code style -> Formatter)

В целом соответствует https://google.github.io/styleguide/javaguide.html, кроме увеличенной длины строки.

Для eclipse можно сделать импорт из файла Файл:RunaWFE.formatter.xml.

Настройки для idea: Файл:IdeaCodeStyle.xml.

Создать новый форматтер на базе Eclipse [build-in].
Увеличить размер Java-строки для форматирования: Line Wrapping -> Maximum line width заменить с 80 на 150.
Comments -> Line width 150
Tab policy -> Spaces only
Применить http://stackoverflow.com/a/12705543

Действия при сохранении (Eclipse: Window -> Preferences -> Java -> Editor -> Save Actions)

Включить

Perform the selected actions in save;
Format source code;
Format edited lines;
Organize imports;
Additional actions. Configure.
Code Style -> Control statements -> Use blocks in if/while/for/do statements. Включить Always.

Порядок импортов

Порядок импортов в классе: импорты, пустая строка, статические импорты (Eclipse: Window -> Preferences -> Organize imports: Remove all; New * ; New static *)

# Соглашение по именованию переменных

Переменные лучше именовать так:

Variable variable: в соответствии с полным названием класса
Variable oldVariable: если переменных данного типа несколько в текущем контексте специфика отражается префиксом
VeryLongType type: сокращение по суффиксу в случае длинного названия класса
Variable oldVar: неправильное сокращение

Такие правила несложно соблюдать (в Eclipse Ctrl + Space) и они стимулируют называть классы более правильно (например VeryLongType вместо TypeVeryLong). При полном соответствии Eclipse также переименовывает названия переменных при переименовании класса.

# Соглашение по оформлению кода XML

Отступ 1 tab.

Но для plugin.xml - так как делает eclipse, там другие правила.

# Соглашение по ascii properties

Строки в нижнем регистре (а-ля \u0441\u043a\u0440\u0438\u043f\u0442\u044b). Так делает плагин http://propedit.osdn.jp/eclipse/updates (http://propedit.sourceforge.jp/eclipse/updates/).

# Соглашение по оформлению кода JS, XHTML, CSS

https://contribute.jquery.org/style-guide/js/ (за исключением пробелов в аргументах js) (отступы табы)

# Работа с багами и задачами

Все они у нас сейчас называются тикеты: https://sourceforge.net/p/runawfe/bugs/

Состояния у них 3:

open[*] - открыт, нужно делать тому, на кого он назначен
pending[*] - выполнен, переведён на тестирование
closed[*] - закрыт, тестировать не нужно

При выполнении тикета, его статус нужно перевести в:

pending[*] - если нет уверенности что всё приведено в порядок
closed[*] - если тестирование проводилось и всё в порядке

При изменении статуса переназначать, думаю, нет необходимости.

В левой колонке добавили и изменили, сейчас:

Closed Tickets - все закрытые
For Testing - все для тестирования
My Tickets - все открытые для текущего пользователя
Open Tickets - все открытые

При создании нового тикета просьба сразу его назначать:

по дистрибутивам Linux - Даниилу (efnez)
по дистрибутивам Windows - Алексею (kanaal)
если известен исполнитель работ - ему
по остальным - Сергею (gritsenko_s)

# Работа с версиями

В проекте используется нумерация версий в виде X.Y.Z, где

X - версия, обновляемая при существенных изменениях в ядре
Y - версия, обновляемая при добавлении значимого нового функционала
Z - версия, обновляемая при добавлении не значимого нового функционала или при исправлении ошибок

В trunk-е версия проектов устанавливается в виде X.Y.Z-SNAPSHOT (например 4.1.1-SNAPSHOT), где версия X.Y.Z - версия следующего релиза.

# Выпуск релиза

# Сервер

1. В master изменить версии, например с помощью команд

В папке wfe-app

mvn versions:set -DgenerateBackupPoms=false -DnewVersion=4.X.X

Данная команда не обновляет версии в некоторых проектах, например wfe-webservice-client.

2. Закоммитить

3. Собрать бинарный и Windows-дистритутив (инструкция, https://rm.processtech.ru/issues/342), проверить

4. Запушить, создать релиз в https://github.com/processtech/runawfe-server/releases

TODO. Загрузить артефакты в публичный репозиторий

https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

5. По аналогии с п.1 увеличить версию до 4.X.(X+1)-SNAPSHOT либо 4.(X+1).X-SNAPSHOT

# Редактор

1. В master изменить версии, например с помощью команд

В папке gpd/plugins

mvn tycho-versions:set-version -DnewVersion=4.X.X

2. Закоммитить

3. Сделать [DesignerDeveloperGuide#BuildingFromSourcesUsingMaven сборку] и проверить его

4. Запушить, создать релиз в https://github.com/processtech/runawfe-devstudio/releases

5. По аналогии с п.1 увеличить версию до 4.X.(X+1)-SNAPSHOT либо 4.(X+1).X-SNAPSHOT

В случае проблем после выпуска релиза сделать из тега ветку releaseX.Y.Z, добавить исправления и сделать тег из неё заново (ветку придётся оставить)

# Работа с документацией

Правила оформления:

не использовать в документации излишние слова runawfe и пр.
заголовки всех страниц устанавливаются с помощью шаблона PageHeading
все заголовки, которые представляют собой интерес как якори (anchor) для отправки ссылкой, оформить с использованием шаблона Title
сноски оформить с использованием шаблонов Note (замечание) и Warning (предупреждение)
использовать унифицированный словарь терминов (TODO: составить его)

Для отправки ссылки, не содержащий non-ascii символов, на определённый раздел нужно из меню выбрать раздел (или спозиционировать другим образом), после этого нажать на решётке и скопировать из строки браузера URL.

DevelopersInfo

Содержание