Как информация о версии должна быть записана?
Необходимо выполнить следующие шаги
- Создать новое угловое приложение, используя - ng new my-app
- Перейдите в папку my-app
- Выполнить команду - ng add @ nativescript / schematics
- Наконец, выполните tns run android --bundle - это сгенерирует автоматически сгенерированную страницу в эмуляторе.
Я вижу некоторые различия в настройках проекта.
5 ответов
Общедоступная информация о версии должна содержать, по крайней мере:
- выпуск, buildnumber
- все исправленные общедоступные ошибки
- все добавленные общедоступные опции
информация о версии QA должна содержать, по крайней мере:
- выпуск, buildnumber
- все исправленные ошибки включая ошибку номер
- все дополнительные функции включая ссылки для разработки документов
Рассматривают аудиторию и пытаются думать, в чем они нуждаются.
другой вещью добавить является новая или прекращенная поддержка определенных платформ. (Например, мы выходим из поддержки Win3.1 и добавили Vista 64 бита).
Это действительно зависит от аудитории. Для технических пользователей (например, разработчики, которые используют Ваш API) можно быть очень техническими. На других высокоуровневых конечных пользователях конца приложения Вы создали, мог бы только интересоваться новыми возможностями и существенными изменениями.
Промежуточный нетехнические пользователи, которые нуждаются в деталях также, например, поддерживают отдел. Для тех людей можно дать подробное описание без низкого уровня, технические специфические особенности, например, "Исправили ошибку, где запись не была сохранена в базе данных"..
Если у Вас есть система управления проектами/отслеживания ошибки, необходимо определенно использовать это для генерации информации о версии. Trac и Redmine в особенности очень хороши в этом.
точки Выпуска должны иметь несколько свойств, IMO:
- Помнят Вашу аудиторию. , Если это - приложение для iPhone, немногие собираются заботиться о том, что была зафиксирована конкретная логическая ошибка на строке 572 в классе Foo. Но они будут заботиться много о "приложении, теперь чувствительно к акселерометру".
- Суммируют новые разработки, функции и bugfixes широким, широким способом, если это возможно. Если можно связать их тематически (например, "мы реализовали дженерики и анонимные типы"), короткая аннотация об этом является хорошим способом дать людям большое изображение.
- Перечисляют определенные вещи, которые были починены со ссылками на Ваше общедоступное средство отслеживания ошибки, если таковые имеются. Это может обычно быть автоматически сгенерировано.
- не обеспечивают мучительную деталь. Один - или сводки с двумя лайнерами каждой вещи, которая была добавлена или починена, должно быть достаточным.
- Всегда включают определенные идентификаторы выпуска (например, "v.1.4.5"), как соответствующие.
Одна лучшая практика с информацией о версии, по-моему, является автоматизацией. Если существуют определенные лучшие практики для системы управления версиями, отправляют сообщения ( http://drupal.org/node/52287 ), можно создать информацию о версии автоматизированным сценарием ( http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/cvs-release-notes/ ). Это создало бы действительно хорошую информацию о версии: http://drupal.org/node/226165