На них больше точек, чем бумаги под прохудившейся шариковой ручкой. Они включают в себя кучу чисел, которые кажутся случайными. А что не так с тегами -alpha и -beta?

В идеальном мире мы бы выпустили только одну версию: идеальную версию, которая будет работать отныне и до вечности. Но в последний раз я проверял (проверяет часы), мы не живем в идеальном мире. Поскольку программное обеспечение постоянно меняется, нам всегда нужно делать обновления. Каждое обновление выпускается под определенной версией.

К основным выпускам иногда прикрепляются кодовые имена

Обычно нам известны основные номера версий. Windows 11. iOS 16. Android 12. Обычно они не используются для обозначения чего-либо между выпусками, а скорее используются в качестве рекламной версии.

Если вы использовали Ubuntu, вы, несомненно, узнали прозвище версии в алфавитном порядке для каждого выпуска (Текущий в типе написания — «Кинетический Куду»)

Как правило, это «кодовые имена», популярность которых с годами, похоже, упала. Раньше у нас были Windows XP, Windows Vista и, конечно же, Android Marshmallow. Теперь у нас есть Windows 11. Android 12. Думаю, людям уже все равно.

Тогда есть версии для внутреннего выпуска

Если вы загружали программное обеспечение — особенно программное обеспечение с открытым исходным кодом — вы могли заметить это. Они бывают самых разных форм:

  • Что-то, связанное с датой: например. monocle_polisher-2021-04-03.exe
  • семантический номер версии (см. ниже), например adobe_acrobat-w-a_side_of_flash-0.0.2-rc4.bin
  • Хэш, например. eggs-browns-afe3d7c138c36a807330ae20ee1c.zip (понятно? яйца? картофельные оладьи; любые, кроме шуток, мы доберемся до почему через секунду)

Я уверен, что можно найти и других. Вы можете называть меня придурком и упоминать их в комментариях. Но это самые распространенные.

Каждая команда следует семантике

Независимо от формата, каждая команда следует системе семантической версии, называемой «semver» для людей с карманными протекторами, стаканами из-под кока-колы и черепками.

Обычно это формат <major_version>.<minor_version>.<patch>-<suffix>. <suffix> обычно что-то вроде dev, alpha, beta и т. д.

Зайдите на https://semver.org/, чтобы узнать все подробности о версии и досадить своим знанием своим коллегам.

Но, как и в случае с «Чья линия», все выдумано, а очки не имеют значения!

Да, это правда.

Если вы поклонник «Звездного пути» (и приверженец отслеживания несущественных деталей телешоу), то вы, несомненно, заметили, что между звездными датами оригинального сериала и звездными датами следующего поколения существует разница в звезду (k). .

Это потому, что у команды OS и команды NG были разные методы «планирования» звездной даты.

В оригинальном сериале у Джина Роденберри не было установленного стандарта того, что звездная дата меняется от недели к неделе. Для Next Generation, я думаю, они обратили внимание на все гневные письма фанатов от Trekkies, которые указывали на несоответствия, потому что затем они начали настоящую схему звездной даты.

Видите, даже очень популярные телешоу придумывают! Способ увеличения версии определяется самой командой.

На макроуровне управление версиями больше похоже на Old Trek — дикий дикий запад, где каждая команда делает это по-своему. Но команды часто прибегают к управлению версиями в стиле нового поколения — имея какую-то предсказуемую систему версий, чтобы не раздражать заказчиков или клиентов.

Суффикс (то, что после тире) указывает на ожидаемое качество

Если вы загружаете программное обеспечение от компании, вы, вероятно, слышите разговоры о «бета-версии» или «альфа-версии».

Как и в случае с номерами версий, у каждой команды есть стандартная метрика, показывающая, когда программное обеспечение попадает на эту стадию, но вот «эмпирическое правило», которому нужно следовать:

Ночное (также называемое «скользящим» или «моментальным снимком»)

Не загружайте это, если вы не ЗНАЕТЕ, во что ввязываетесь. Он может даже не компилироваться. В зависимости от программного обеспечения это может даже разрушить вашу систему.

Обычно тот, кто загружает ночные новости, отчаянно нуждается в версии, которая работает, если предыдущая версия была сломана, или пытается что-то сделать с программным обеспечением.

Он называется «ночным», потому что он автоматически компилируется сценарием и помещается в промежуточную среду независимо от того, прошел ли он проверку или нет. Итак, скомпилировано «ночью», когда разработчики спят (разработчик… спит… хахахахаха… *звук рыданий*)

Разработка (или «разработка», «предварительная версия», «кандидат на выпуск» или «исходная версия»)

Это немного странно, потому что о нем не так много говорят. Если у команды есть продукт, который они хотят протестировать, но они сообщают испытуемым, что продукт далек от готовности, они могут выпустить сборку для разработки.

Это несколько протестировано, в отличие от nightly, но все еще не готово для публичного тестирования.

Альфа

Здесь мы подходим к суффиксу, который имеет большее значение для широкой публики.

Альфа, по сути, означает, что «мы начинаем готовить что-то к финальному релизу. Тесты приветствуются, но это ДЕЙСТВИТЕЛЬНО не будет работать в полной мере. Ожидайте ошибок, сообщайте по мере необходимости».

Бета

Вы, наверное, видели, что слово «бета» упоминается чаще, чем слово «альфа»,и на это есть причина. Бета-версии предназначены для предварительного просмотра конечного продукта. По сути значит. «У нас есть вещи, в основном работающие, но есть несколько ошибок здесь или там. Давай, давай обратную связь». Ожидается, что он будет более чистым, чем альфа-версия.

Версии обычно помечаются системой контроля версий.

Конечно, в наши дни, когда вы слышите «система контроля версий», это, скорее всего, git.

Разработчики любят, чтобы соглашения о версиях контролировались системами контроля версий, такими как git. Это помогает поддерживать выпуск в соответствии с функциями.

Помните, ранее я говорил, что иногда к тегу версии прикрепляется хэш? Да, это обычно хеш фиксации — строка, идентифицирующая состояние кода, когда произошла фиксация.

Но часто проекты будут следовать нехешированным версиям в стиле semver. Вы даже можете проверить версию базы кода на Git. Просто нажмите на меню «Ветвь» репозитория и выберите теги.

С помощью GitHub вы также можете просмотреть версию хэша, упомянутую выше, но для этого вам нужно просмотреть историю изменений, скопировать тег, а затем проверить эту версию.

В конце концов, нужно сообщать о последовательных изменениях

Как видите, все делают версии по-разному. Поскольку жизненный цикл разработки программного обеспечения всегда динамичен и меняется, трудно (если вообще возможно) определить, когда нужно увеличить количество патчей.

Итак, если вы работаете в команде, просто уважайте поток. Руководитель команды выбрал версию не просто так. Не нравится - ну на то и капитализм - заводи конкурента! 😆

В этом руководстве я рассмотрел различные свойства, составляющие номер версии.

Я надеюсь, что эта статья оказалась для вас полезной, если да, я прошу вас выполнить хотя бы одно из следующих действий:

👉‍‍ Поделиться этой статьей с тремя друзьями или коллегами?

📢 Комментарий ниже: Есть ли у вас любимый метод версии? Какая самая странная схема версии, которую вы видели?

💓 Подпишитесь на DamnGoodTech на Ko-Fi всего за 7 долларов в месяц. Получайте статьи на 3 дня раньше и получайте благодарность за каждую статью! Это все равно, что нанять тимлида в вашу компанию по разработке программного обеспечения за гораздо меньшую заработную плату. 🙏🏻 Особая благодарность Джеймсу Н. и Люси Р. за вашу поддержку.

💼 Кстати, о найме… Наймите меня в качестве ведущего разработчика в вашу команду.