crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Учет номеров билдов
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Litkevich Yuriy Дата 24.9.2008, 11:47
  я все равно не понял, что такое билд?
если это команда make makefile, то можно действительно в makefile добавить необходимые строчки.

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

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

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

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

Что касается модели X Y Z M, то это уже давно известно :
Major Minor Patch Build
Andrew Selivanov Дата 23.9.2008, 9:23
 
Цитата(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)

Кстати именно база билдов себя оправдала - очень удобно отслеживать что и когда собиралось, какой версии, подверсии, ревизия на тот момент...
Tonal Дата 23.9.2008, 8:35
  Про нужность - оно не нужно, ежели ты делаешь прогу чисто для себя - всегда последний билд.
Если это не так, то релизы нужно как-то уникально именовать/нумеровать, чтобы тестер или пользователь тебе смог сказать на каком конкретно билде произошёл глюк.
Частые способы - ручное инкрементирование перед сборкой (1), автоинкрементирование перед сборкой (2), текущая дата (3), номер ревизии из свина (4).

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

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

П.С. Кстати, как для того же git-а или darcs-а поступать? У них ревизии не нумеруются как в свине, а имеют уникальный хеш. Его, конечно можно так же прописать везде, но птудно себе представить пользователя, который это нормально может по телефону прочитать. :)
ViGOur Дата 23.9.2008, 8:06
  Andrew Selivanov, а что мешает ручками менять? :)
Red Devil Дата 22.9.2008, 17:35
  Для *nix проблем нет, т.к. скрипт можно встроить в makefile.

Я бы хотел обсудить полезность данной фичи. По своему опыту скажу - нулевая, ибо если изменеяется функциональность должна быть и изменена версия продукта, естественно это касается больших проектов, а не лабараторных и курсовых.
Andrew Selivanov Дата 22.9.2008, 15:42
 
Цитата(Litkevich Yuriy @ 22.9.2008, 16:18) *
А что значит учет новеров сборок? Для чего, чем системы управления версиями (SVN, Git) не страивают?

Имеется ввиду build number. Системы управления версиями не могут определить, когда именно ты собрал приложение.
Litkevich Yuriy Дата 22.9.2008, 15:18
  А что значит учет новеров сборок? Для чего, чем системы управления версиями (SVN, Git) не страивают?
Andrew Selivanov Дата 22.9.2008, 15:09
  Предлагаю обсудить тему. Лично я долго искал подходящую именно мне утилиту и в конце концов забил и написал свою (использую в основном в Eclipse, внимание, не для Java, для Java утилит хватает).
Какое то время пытался заюзать MyLar (или как там его переименовали, MyLyn) но показалось неудобно.
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.3.2024, 4:03