Comments 26
Разработчики Хрома и Firefox, похоже, не в курсе :)
У них гонка версий, а не версионирование. Скоро можно будет топ делать за сколько до сотни доберутся.
Когда начнут сразу по 10 за раз прибавлять, так всё ещё быстрее пойдёт!
хм… Зашел посмотреть, какая у меня сейчас версия хрома… Так хром взял, и с 49 обновил до 50-й...)
Прочитал ваш коммент, пошел посмотреть, а какая у меня… обновил хром. Походу вы запустили цепную реакцию :)
Хех. Обычно Хром «пропихивается» несколько дней, иногда — неделю или две и при этом смотрится — не началась ли «цепная реакция» (резко увеличилось количество крешей, например).
Так как речь идёт об ошибках проявляющихся в количества «штук на миллион», то «на кошках» такое не отловишь, увы… А проблемы могут быть реальными, так что сразу на всех выкатывать новую версию опасно…
Так и получается, что новая версия уже есть, но у вас её нет, так как вы стоите где-то в хвосте «очереди». Но если человек полез-таки смотреть какая у него версия, то, стало быть, ему это отчего-то важно. В этом случае его переставляют в начало оной очереди.
Так что эффект «пошел посмотреть, а какая у меня… обновил хром» — это не «совпадение», а «фича».
Так как речь идёт об ошибках проявляющихся в количества «штук на миллион», то «на кошках» такое не отловишь, увы… А проблемы могут быть реальными, так что сразу на всех выкатывать новую версию опасно…
Так и получается, что новая версия уже есть, но у вас её нет, так как вы стоите где-то в хвосте «очереди». Но если человек полез-таки смотреть какая у него версия, то, стало быть, ему это отчего-то важно. В этом случае его переставляют в начало оной очереди.
Так что эффект «пошел посмотреть, а какая у меня… обновил хром» — это не «совпадение», а «фича».
Semver предназначен для версионирования продукта, предоставляющего внешний api. Chrome и Firefox скорее являются продуктом для пользователей.
В курсе.
На самом деле они используют семантическое версионирование. Просто у таких проектов, которые состоят из очень большого числа компонентов и очень большого числа разных API каждая версия является мажорной. Потому что в каждой версии будет содержаться новое мажорное несовместимое изменение какого-нибудь компонента (то рендеринг HTML, то свойства CSS, то Javascript, то интерфейс, то ещё что-то).
То же самое касается операционных систем, (и их ядер, оттого и смена версионирования Линукса).
Семантическая версия плохо с
Хорошая статья, но я бы не "предлагал", а "настоятельно рекомендовал" использовать semver.
Простите, а как это соотносится с debian'овской системой нумерации пакетов? И где эпоха в версии? Почему «semver» следует предпочесть существующей модели именования версий, в которой учтено всё на свете — от взбрыков разработчиков по переименованию системы нумерации версии (windows 95 и windows 10), до особенностей системы сборки?
Дборотная версия выглядит примерно так:
2:34.5.6-nmu7+8~20160309142337.19~1.gbp08c0c0
2 — номер эпохи. Означает, что до «34» была какая-то другая версия. Например, «2000», и это «починили».
34.5.6 — что хотите. Версия и версия.
nmu — собиралось не мейнтейнером. Убунтововды там «ubuntu» пишут.
7 — версия сбоки
+ и далее — версия из гита (что именно собиралось). Год, дата, время, потом после тильды — очередная локальная эпоха и gbp (кто собирал) и первые цифры коммита из которого собиралось.
Это я не фантазирую, это индустриальный стандарт.
Дборотная версия выглядит примерно так:
2:34.5.6-nmu7+8~20160309142337.19~1.gbp08c0c0
2 — номер эпохи. Означает, что до «34» была какая-то другая версия. Например, «2000», и это «починили».
34.5.6 — что хотите. Версия и версия.
nmu — собиралось не мейнтейнером. Убунтововды там «ubuntu» пишут.
7 — версия сбоки
+ и далее — версия из гита (что именно собиралось). Год, дата, время, потом после тильды — очередная локальная эпоха и gbp (кто собирал) и первые цифры коммита из которого собиралось.
Это я не фантазирую, это индустриальный стандарт.
Предполагаю, что чем проще — тем лучше. И потом, это же для мейнстрима — node.js, go, python, ruby, c#, java итд. Для энтерпрайзов с чпуксом наперевес вполне можно использовать и что-то более «тяжеловесное».
Это версия питоновской приложухи. Мейнстримовая. Без энтерпрайза.
По моему — это бессмысленный спор о терминах. Есть symver. Фигня вопрос: поддерживается (с некоторыми вариациями) для библиотек (но не дла названий сами приложений!) в GCC и libtool, для пакетов в NPM и в Gentoo, а также в куче разных других мест.
Есть нумерация пакетов в Debian'а. Применяется, вы не поверите, для нумерации пакетов в Debian'е. Причём для библиотек, вы не поверите, Debian использует как раз symver тоже. Правда в извращённом «ручном» виде, но использует (именно поэтому там есть пакеты libc6 и liblzma5, а не просто libc и liblzma).
Что считать мейнстримом — дело ваше. Но если вы собираете библиотеку — то лучше, наверное, использовать систему, предназначенную для работы с библиотеками, а не что-то что используется в совсем других случаях и совсем для другого.
Есть нумерация пакетов в Debian'а. Применяется, вы не поверите, для нумерации пакетов в Debian'е. Причём для библиотек, вы не поверите, Debian использует как раз symver тоже. Правда в извращённом «ручном» виде, но использует (именно поэтому там есть пакеты libc6 и liblzma5, а не просто libc и liblzma).
Что считать мейнстримом — дело ваше. Но если вы собираете библиотеку — то лучше, наверное, использовать систему, предназначенную для работы с библиотеками, а не что-то что используется в совсем других случаях и совсем для другого.
semver — это один из способов нумеровать версии у одного данного конкретного проекта. Система Debian'а — это способ нумеровать версии у пакетов в дистрибутиве, где почти каждый пакет имеет апстрим. Т. е. апстрим выпустил новую версию, стоИт задача правильно дать номер версии для соответствующего пакета Debian. Т. е. задачи разные у этих двух нумераций.
Упомянутый номер эпохи ярко это демонстрирует. Зачем нужен номер эпохи в Debian'е? На случай, если апстрим тупанул и сменил систему нумерации. Допустим, апстим выпускал версии под номерами 10.0, 20.0, 30.0 (ну мало ли), а потом зачем-то решил убрать ноль и выпустил версию номер 4.0. Тогда мейнтейнеры пакета Debian увеличивают на единицу номер эпохи, чтобы не сломалось сравнение номеров версий.
Ну вот я про это и говорю. Semver не для задачи подготовки пакетов некоего апстримного пакета. Там эти взбрыки учитывать не надо.
Далее, semver на то и называется semver, что в нём учитывается semantic, семантика, смысл. Major, minor и patch выбираются исходя из смысла нового релиза, исходя из его предназначения, исходя из того, насколько сильно он отличается от предыдущих, насколько там важные фичи и так далее, и тому подобное. В Debian'е главный компонент номера версии (34.5.6 в вашем примере) не имеет никакого смысла в рамках всего проекта Debian в целом. Потому что он просто повторяет номер версии апстрима, а тот уже вкладывает в него смысл по своему усмотрению, например, с помощью того же semver.
Эту инфу можно занести в meta semver. Никакого стандарта на устройство этого meta не нужно, meta — это просто for your information, meta игнорируется при сравнении версий
Это особенности чисто дебианого процесса разработки. Это не нужно в semver, в системе нумерации для всех и вся.
Этот номер означает, каким по счёту является данный пакет Debian на основе одного и того же данного upstream пакета. В semver это не нужно, там нет upstream'а и downstream'а.
Всё это можно в meta, без стандарта на точное устройство meta, я уже говорил
Упомянутый номер эпохи ярко это демонстрирует. Зачем нужен номер эпохи в Debian'е? На случай, если апстрим тупанул и сменил систему нумерации. Допустим, апстим выпускал версии под номерами 10.0, 20.0, 30.0 (ну мало ли), а потом зачем-то решил убрать ноль и выпустил версию номер 4.0. Тогда мейнтейнеры пакета Debian увеличивают на единицу номер эпохи, чтобы не сломалось сравнение номеров версий.
от взбрыков разработчиков по переименованию системы нумерации версии
Ну вот я про это и говорю. Semver не для задачи подготовки пакетов некоего апстримного пакета. Там эти взбрыки учитывать не надо.
Далее, semver на то и называется semver, что в нём учитывается semantic, семантика, смысл. Major, minor и patch выбираются исходя из смысла нового релиза, исходя из его предназначения, исходя из того, насколько сильно он отличается от предыдущих, насколько там важные фичи и так далее, и тому подобное. В Debian'е главный компонент номера версии (34.5.6 в вашем примере) не имеет никакого смысла в рамках всего проекта Debian в целом. Потому что он просто повторяет номер версии апстрима, а тот уже вкладывает в него смысл по своему усмотрению, например, с помощью того же semver.
до особенностей системы сборки?
Эту инфу можно занести в meta semver. Никакого стандарта на устройство этого meta не нужно, meta — это просто for your information, meta игнорируется при сравнении версий
nmu — собиралось не мейнтейнером
Это особенности чисто дебианого процесса разработки. Это не нужно в semver, в системе нумерации для всех и вся.
7 — версия сбоки
Этот номер означает, каким по счёту является данный пакет Debian на основе одного и того же данного upstream пакета. В semver это не нужно, там нет upstream'а и downstream'а.
+ и далее — версия из гита (что именно собиралось). Год, дата, время, потом после тильды — очередная локальная эпоха и gbp (кто собирал) и первые цифры коммита из которого собиралось.
Всё это можно в meta, без стандарта на точное устройство meta, я уже говорил
34.5.6 — что хотите. Версия и версия.Вот здесь и предлагается использовать semver
deleted
Поправьте название, пожалуйста.
Правильное: v3.14.1592-beta6:…
Правильное: v3.14.1592-beta6:…
Спецификация, безусловно, прекрасная, но вот как номер версии, удовлетворяющий ей, сгенерировать автоматически из git — я, например, не представляю :(
Если делать, «как все», добавляя в репозиторий теги с minor.major (например, «v1.0») и вызывать git describe, то patch version будет добавляться через тире, вкупе с хэшем коммита с префиксом g, например, 1.0-42-gdeadbeef.
Если делать, «как все», добавляя в репозиторий теги с minor.major (например, «v1.0») и вызывать git describe, то patch version будет добавляться через тире, вкупе с хэшем коммита с префиксом g, например, 1.0-42-gdeadbeef.
Либо я ничего не понимаю, либо одно из двух. Сгенерировать номер версии автоматически нельзя. Какой смысл в автоматически сгенерированной версии? Кому и о чём она будет говорить? О том конкретно из каких исходников вы собрали ту или иную библиотеку? Ну так это номер билда, а не номер версии.
Номер версии же должен говорить о двух простых вещах: можно ли мне обновляться и стоит ли это делать. symver даёт простые правила: если первая цифра изменилась — обновляться нельзя, так как поломана совместимость. Если последняя цифра изменилась — то обновляться нужно и важно, так как никаких новых вещей в релизе нет, но ошибки и проблемы — поправлены. Если изменилась средняя цифра — то обновляться можно, но нужно всё протестировать (новая функциональность — она, знаете ли, чревата).
Откуда git сможет получить информацию о том — как влияют на код ваши изменения и, соответственно, какую цифирьку увеличивать? Это только вы можете сделать…
Номер версии же должен говорить о двух простых вещах: можно ли мне обновляться и стоит ли это делать. symver даёт простые правила: если первая цифра изменилась — обновляться нельзя, так как поломана совместимость. Если последняя цифра изменилась — то обновляться нужно и важно, так как никаких новых вещей в релизе нет, но ошибки и проблемы — поправлены. Если изменилась средняя цифра — то обновляться можно, но нужно всё протестировать (новая функциональность — она, знаете ли, чревата).
Откуда git сможет получить информацию о том — как влияют на код ваши изменения и, соответственно, какую цифирьку увеличивать? Это только вы можете сделать…
Мы для автоматического генерирования версий используем GitVersion.
Очень удобная штука.
Очень удобная штука.
UFO just landed and posted this here
^1.2.3 обозначает совместимость на уровне “major” версии. Это синтаксический сахар для записи “>= 1.2.3, < 2.0.0”. Используется для указания “самой свежей версии зависимости, все еще совместимой по API”.
Мне кажется тут закралась ошибка, так как ^ обозначает совместимость на уровне «minor», версии, а не «major», особенно это бросается в глаза на фоне следующего абзаца в тексте про "~"
Sign up to leave a comment.
v3.14.1592-beta2: все, что вы хотели знать о семантическом версионировании