Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Учет номеров билдов
Форум на CrossPlatform.RU > Разработка > Инструменты разработчика
Andrew Selivanov
Предлагаю обсудить тему. Лично я долго искал подходящую именно мне утилиту и в конце концов забил и написал свою (использую в основном в Eclipse, внимание, не для Java, для Java утилит хватает).
Какое то время пытался заюзать MyLar (или как там его переименовали, MyLyn) но показалось неудобно.
Litkevich Yuriy
А что значит учет новеров сборок? Для чего, чем системы управления версиями (SVN, Git) не страивают?
Andrew Selivanov
Цитата(Litkevich Yuriy @ 22.9.2008, 16:18) *
А что значит учет новеров сборок? Для чего, чем системы управления версиями (SVN, Git) не страивают?

Имеется ввиду build number. Системы управления версиями не могут определить, когда именно ты собрал приложение.
Red Devil
Для *nix проблем нет, т.к. скрипт можно встроить в makefile.

Я бы хотел обсудить полезность данной фичи. По своему опыту скажу - нулевая, ибо если изменеяется функциональность должна быть и изменена версия продукта, естественно это касается больших проектов, а не лабараторных и курсовых.
ViGOur
Andrew Selivanov, а что мешает ручками менять? :)
Tonal
Про нужность - оно не нужно, ежели ты делаешь прогу чисто для себя - всегда последний билд.
Если это не так, то релизы нужно как-то уникально именовать/нумеровать, чтобы тестер или пользователь тебе смог сказать на каком конкретно билде произошёл глюк.
Частые способы - ручное инкрементирование перед сборкой (1), автоинкрементирование перед сборкой (2), текущая дата (3), номер ревизии из свина (4).

Ручками плохо, т.к. можно забыть, или изменить не туда по запарке (1).
Кроме того, ежели не дай бог, сборка у может выпускаться больше чем с одного места, то возможны конфликты (1, 2).
Текущая дата всем хороша, но внутренних билдов возможно несколько в день хотя можно включить время - но тогда возможны непонятки в распределённых командах (3) :).

Мы используем ревизию из свина.
Дополнительный плюс в том, что эта ревизия идёт и в About-е, и в виндовых ресурсах (как 3я цифра), и в заголовке окна.
Т.е. пользователь её сообщит безо всяких проблем. :)

П.С. Кстати, как для того же git-а или darcs-а поступать? У них ревизии не нумеруются как в свине, а имеют уникальный хеш. Его, конечно можно так же прописать везде, но птудно себе представить пользователя, который это нормально может по телефону прочитать. :)
Andrew Selivanov
Цитата(Tonal @ 23.9.2008, 9:35) *
Про нужность - оно не нужно, ежели ты делаешь прогу чисто для себя - всегда последний билд.
Если это не так, то релизы нужно как-то уникально именовать/нумеровать, чтобы тестер или пользователь тебе смог сказать на каком конкретно билде произошёл глюк.
Частые способы - ручное инкрементирование перед сборкой (1), автоинкрементирование перед сборкой (2), текущая дата (3), номер ревизии из свина (4).

Ручками плохо, т.к. можно забыть, или изменить не туда по запарке (1).
Кроме того, ежели не дай бог, сборка у может выпускаться больше чем с одного места, то возможны конфликты (1, 2).
Текущая дата всем хороша, но внутренних билдов возможно несколько в день хотя можно включить время - но тогда возможны непонятки в распределённых командах (3) :).

Мы используем ревизию из свина.
Дополнительный плюс в том, что эта ревизия идёт и в About-е, и в виндовых ресурсах (как 3я цифра), и в заголовке окна.
Т.е. пользователь её сообщит безо всяких проблем. :)

П.С. Кстати, как для того же git-а или darcs-а поступать? У них ревизии не нумеруются как в свине, а имеют уникальный хеш. Его, конечно можно так же прописать везде, но птудно себе представить пользователя, который это нормально может по телефону прочитать. :)


Ну я сделал себе такую модель: X.Y.Z.M
X - номер версии (задаю переменной в среде разработки - в моем случае Eclipse)
Y - номер подверсии (задаю переменной в среде разработки - в моем случае Eclipse)
Z - revision (в моем случае из SVN)
M - номер билда (все билды [номера] со временем сборки и путями хранятся в базе Sqlite)

Кстати именно база билдов себя оправдала - очень удобно отслеживать что и когда собиралось, какой версии, подверсии, ревизия на тот момент...
Red Devil
Цитата(Tonal @ 23.9.2008, 8:35) *
Если это не так, то релизы нужно как-то уникально именовать/нумеровать, чтобы тестер или пользователь тебе смог сказать на каком конкретно билде произошёл глюк.

Цитата(Red Devil @ 22.9.2008, 17:35) *
ибо если изменеяется функциональность должна быть и изменена версия продукта

Билд - это по сути информация нужная разработчику.

Что касается модели X Y Z M, то это уже давно известно :
Major Minor Patch Build
Litkevich Yuriy
я все равно не понял, что такое билд?
если это команда make makefile, то можно действительно в makefile добавить необходимые строчки.

Цитата(Tonal @ 23.9.2008, 12:35) *
Если это не так, то релизы нужно как-то уникально именовать/нумеровать, чтобы тестер или пользователь тебе смог сказать на каком конкретно билде произошёл глюк.
Опять не понятно, ну сказал тебе пользователь "билд 13749" и что? Ты его где возьмешь? Наверняка из хранилища Системы управления версиями (СУВ), вот номер правки туда и суй.

а для сабственного удобства заведи правило, пересобрал приложение -> фиксируй правку а в коментарий пиши, например, "Build" из лога можно все это дело вытащить, примеров для линя много как использовать совместно команды svn * и cat *
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.