Лучшая практика: управление версиями программного обеспечения [закрывается]
Есть ли какая-либо инструкция или стандартная лучшая практика, как присвоить версию программному обеспечению, которое Вы разрабатываете в свое свободное время для забавы, но тем не менее будете использоваться некоторыми людьми? Я думаю, что необходимо присвоить версию такому программному обеспечению так, чтобы Вы знали о с версией, каждый говорит о (например, для устранения ошибки, поддержки, и так далее).
Но где я запускаю управление версиями? 0.0.0? или 0.0? И затем как я увеличиваю числа? главное изменение release.minor? и разве кто-либо не должен соглашаться на систему управления версиями быть другой версией? или это только для версий, которые используются продуктивным способом?
7 ответов
Вам следует начать с версии 1, если вы не знаете, что первая версия, которую вы «выпускаете», в некотором роде неполная.
Что касается того, как увеличивать количество версий, решать вам, но используйте нумерацию основных и второстепенных сборок в качестве руководства.
Необязательно иметь каждую версию, которую вы передаете в систему управления версиями, как другую версию - скоро у вас действительно будет очень большой номер версии. Вам нужно только увеличить номер версии (каким-то образом), когда вы выпускаете новую версию для внешнего мира.
Итак, если вы сделаете серьезное изменение, перейдите с версии 1.0.0.0 на версию 2.0.0.0 (например, вы перешли с WinForms на WPF). Если вы сделаете меньшее изменение, перейдите с 1.0.0.0 на 1.1.0.0 (вы добавили поддержку файлов png). Если вы внесете незначительные изменения, перейдите с 1.0.0.0 на 1.0.1.0 (вы исправили некоторые ошибки).
Если вы действительно хотите получить подробную информацию, используйте последний номер в качестве номера сборки, который будет увеличиваться при каждой проверке / фиксации (но я думаю, что это заходит слишком далеко).
Основной ответ - «Это зависит от обстоятельств».
Какова ваша цель в управлении версиями? Многие люди используют version.revision.build и только рекламируют version.revision всему миру, поскольку это версия выпуска, а не версия для разработчиков. Если вы воспользуетесь «версией» для регистрации, то быстро обнаружите, что номера ваших версий становятся большими.
Если вы планируете свой проект, я бы увеличил версию для выпусков с незначительными изменениями и увеличил версию для выпусков с существенными изменениями, исправлениями ошибок или функциональными возможностями / функциями. Если вы предлагаете бета-версии или выпуски с ночным типом сборки, расширьте управление версиями, включив сборку и увеличивая ее с каждым выпуском.
Тем не менее, в конце концов, решать вам, и это должно иметь для вас смысл.
I в основном следуйте этому шаблону:
начинаю с 0.1.0
когда он готов, я разветвляю код в исходном репозитории, тег 0.1.0 и создаю ветвь 0.1.0, голова / ствол становится 0.2.0-моментальным снимком или что-то подобное
Я добавляю новые функции только в магистраль, но исправляю обратную связь в ветку, и со временем я выпускаю из нее 0.1.1, 0.1.2, ...
Я объявляю версию 1.0.0, когда продукт считается функционально завершенным и с этого момента не имеет серьезных недостатков
- каждый может решить, когда увеличивать основную версию ...
Как говорит Махеш: Я бы использовал тип управления версиями x.y.z
x - основной выпуск y - второстепенный выпуск z - номер сборки
, возможно, вы захотите добавить дату и время, возможно, вместо z.
Вы увеличиваете второстепенный выпуск, когда у вас есть другой выпуск. Основной выпуск, вероятно, останется 0 или 1, вы измените это, когда действительно внесете серьезные изменения (часто, когда ваше программное обеспечение находится в точке, где оно не имеет обратной совместимости с предыдущими выпусками, или вы изменили всю свою структуру)
Вы знаете, что всегда можете проверить, что делают другие. Программное обеспечение с открытым исходным кодом, как правило, разрешает доступ к своим репозиториям. Например, вы можете указать в своем браузере SVN на http://svn.doctrine-project.org и взглянуть на систему управления версиями, используемую в реальном проекте.
Номера версий, теги, все это есть.
Мы используем abcd, где
- a - основной (увеличивается при доставке клиенту)
- b - второстепенный (увеличивается при доставке клиенту)
- c - версия (увеличивается на внутреннем релизов)
- d - build (увеличивается круиз-контролем)
Я бы использовал xyz вид управления версиями
x - основной выпуск
y - второстепенный выпуск
z - номер сборки