Здравствуйте, Sinix, Вы писали:
S>The Semantic Versioning specification is authored by Tom Preston-Werner, inventor of Gravatars and cofounder of GitHub.
Здравствуйте, lvlsynaps, Вы писали:
L>Я хочу понять на примере для чего создан семвер и в чем его сильные стороны, потому что для десктопных приложений это натягивание.
В топике на это отвечали по меньшей мере трижды. И на самом сайте на нескольких языках — тоже.
L>У меня небольшая программа,которая принимает данные с одной системы выбивает чеки и передает в другую систему, что в ней является публичным API?
Выделенное.
— Данные принимаются/поглощаются каким-то интерфейсом (формат данных описан и т.п.)
— На основе этих данных производятся чеков (формат данных описан и т.п.)
— Эти чеки передаются в другую систему (формат данных описан и т.п.)
Любое обратно несовместимое изменение в одном из этих трех — переход на новую версию. Например, решили поменять формат, в котором чеки передаются в другую систему. Или формат, в котором чеки производятся. Или поменяли формат принимаемых данных. И т.п.
Здравствуйте, lvlsynaps, Вы писали:
L>Т.е. моя программа стала взаимодействовать с другими и я с версии скажем 0.X.Y перейду на версию 1.X.Y так что ли?
Просто прочитай наконец спецификацию.
4.Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
5.Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
...
FAQ
>How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
>How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
Куда проще-то?
> А что делать если программа с другими системами не взаимодействует, то получается эта система версионирования не подходит?
Given a version number MAJOR.MINOR.PATCH, increment the:
1.MAJOR version when you make incompatible API changes,
2.MINOR version when you add functionality in a backwards-compatible manner, and
3.PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
определение "ломающим изменениям" даёт сам автор. Собственно, вся суть semver — уложить в три цифры публичный контракт софта. Грубо говоря,
* 1.0.0 -> 1.0.2 — поправили баги, спокойно обновляемся (hotfix).
* 1.0.2 -> 1.1.0 — о, новые фичи! (%product_name% update 1)
* 1.1.0 -> 2.0.0 — новый релиз.
Чисто технически никто не запрещает выпускать новый релиз на любой чих (превед, FF!), или ломать совместимость каждым патчем (правда, Go?). Но это говорит куда больше о бардаке в разработке, чем о "плохом semver".
L>Как мне быть в моем проекте среднего размера (15 тыс строк кода),
Вам для каких целей? Если для себя, то делайте как удобно.
Если номер версии используется в названии продукта, то там другая философия: изменение первой цифры — платное обновление лицензии, изменение второй — бесплатный апдейт, ну может быть и платный, кстати , тогда бесплатный — третья цифра. Номера версии меняются в зависимости от потока платежей, как только он иссякает, меняем первую цифру. Но это уже к программированию отношения не имеет.
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
Так натягивается же.
f> Повсеместное форсирование semver — не учитывает главного, — а именно, потребностей разработчика, и сложности (или простоты) софта. Или вообще назначения.
Учитывает достаточно чтобы покрыть и сложный (не путаем с переусложнённым), и простой софт.
f> >Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
f> Это не стандарт, и даже не рекомендация.
Спецификация, набор правил, соглашение. Какая разница?
f> В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту?
Плохая аналогия. Не надо путать культурные ценности и инженерную дисциплину.
f> Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия.
Зачем у тебя в розетке 220 вольт? Ведь нет никакой необходимости, и 22, и 2200 — точно такие же вольты.
f> ·>Исходный код обязан каждый раз порождать идентичную бинарную сборку. Поэтому — какая разница? Если не так — значит в процессе разработки бардак и нет такого понятия как reproducible build.
f> Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb.
Бардак, что ещё сказать... У нас нет "установленного софта". Точная версия jdk, python, и прочего явно указана в исходном коде.
f> Кроме того библиотека версии A.B.C может поставляться в 3-х упаковках: с UTF8 строками, с UTF16 строками и UTF32. Как автору библиотеки — тебе может быть фиолетово, для тебя — это всё есть A.B.C. Для потребителей артефактов — это 3 разных версии, с несовместимым ABI.
Для потребителей это три разных библиотеки. Потребитель скорее всего будет использовать одну из них (или так же делать три упаковки) и отслеживать изменения именно "A.B.C".
f> ·>А какая разница конечному пользователю почему изменилось поведение — из-за изменения самого кода или какой-то зависимости? И да, делаем мажорную версию, если надо. f> Тут обратная ситуация. Нам как потребителям-девелоперам всё ещё интересная версия, которая бы не была рандомным числом.
Не понял мысль. Что-то у тебя падежов не склоняется.
f> ·>По-моему стандарт достаточно универсален, поэтому можно вписать всё.
f> За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease.
А какой смысл вложен в этот postrelease? Почему нельзя сделать A.B.(C+1)?
f> Вообще в интернете если поискать есть полно критики semver.
Я нашел два:
1. Effort is required to do the right thing
2. This will be an ongoing effort until downstream projects adopt Semantic Versioning.
Хех...
f> Build metadata не являются частью версии в semver2 и из сравнения исключаются.
И правильно что исключаются. Сравнение нужно для чего? Для того, чтобы принять решение — нужно ли обновление версии или нет и оценить сложность. Я вот помню уже попадал на такую граблю, когда выбирал последний релиз смотря на строки типа "15.28.24.64.4229", "15.28.24.64.4532", "15.28.24.86.4532" .
f> При этом очевидно что 64 и 86 — есть весьма разные билды, которые живут параллельно -> следовательно платформу невозможно положить в build metadata. Что касатеся очевидности, то предшествование версий обеспечивается принятой схемой версионирования, и некоторые из них — очевидны. Другие нет. При этом семантика схемы — обеспечивается автором. На ручнике или с помощью тулзов. Поэтому кроме как говорить о возможной рекомендации — не приходится.
Но уж точно платформу нельзя класть в значимый номер версии.
Понятно, конечно, что можно делать. Но это вовсе не значит, что так нужно делать.
f> В случае с debian — это именно версия пакета. Т.к. этот пакет собирается особым образом, наносятя патчи, конфигурируются и прочие вещи. Это позволяет пушить изменения (исправления), в том числе и секьюрити фиксы, для библиотек, базовая версия которых к тому моменту — не изменилась. Вместе с тем, это не параллельное версионирование. Это больше похоже на бранч.
А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю?
f> Ещё раз — semver пихать куда не попадя — не нужно. f> Для продуктов может быть достаточно A.B. Для библиотек A.B.C, мы всё равно все к этом привыкли.
Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться.
f> Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость.
Извини, но софтостроение — инженерная дисциплина. Там не чувствовать надо, а рационально решать.
f> Короче говоря — как только будете заниматься маппингом технологических версий на внешние, только лишь для того, что бы угодить тулзам, которые с другими схемами версий не работают — тогда станет всё понятно.
semver ничего о внешних (маркетинговых) версиях не говорит, хоть Lollipop, хоть Vista.
Воронков Василий написал что он в своих проектах использует
1.2.3.4
1 и 2 — верхние ревизии. Их изменение предполагает серьезные изменения в проге, которые приводят (могут привести) к несовместимости со старыми версиями.
Изменение самой верхней ревизии — это как правило кардинальное изменение архитектуры, серьезная переработка. Хотя определенный момент произвола — что выбрать 1.2 или 2.0 — все же остается. И зачастую это сугубо на совести разработчика.
3 — номер билда.
4 — все используют по разному. Например, можно резервировать данную ревизию для того, чтобы осталась возможность патчить прогу, не увеличивая остальные версии. Или для отметки дебужных билдов.
Пока он не ответил, может кто-нибудь поможет мне разобраться в теме?
Что такое номер билда? Случайно не термин автоматической системы сборки?
И 4 число — как-то связано с svn?
Как мне быть в моем проекте среднего размера (15 тыс строк кода), в котором не используется
автоматическая сборка, я так понимаю мне номер билда не нужен как и номер ревизии, и еще вопрос зачем вообще нужен номер билда и ревизии?
И еще вопрос сейчас мой проект в эксплуатации но содержит ряд ошибок и глюков и часть функционала не протестирована, мне нравится предложенная Василием система версионирования и я планирую ее взять себе за исключением билда и ревизии, и с небольшой модернизацией, первое число — архитектура или стабильность в случае перехода от 0 к 1 (психологический момент): третье число для отображения исправлений.
А теперь кто дочитал до сюда и все еще хочет мне помочь пожалуйста прочтите мой план версий.
Мой проект — касса, которая может принимает платежи и выдает чеки.
План версий такой:
0.1.0- обработка заказов оплаченных наличными
0.1.1 — исправление первого найденного бага в данной версии
0.1.I — исправление I-го бага найденного в версии.
Пусть всего я нашел и исправил 2 ошибки получилась версия 0.1.2, теперь я добавил новый функционал скажем обработка заказов предоплаченных заранее банк. картой, версия должна быть 0.2.0 или 0.2.2?
Теперь я выпустил релиз с предоплаченными заказами и нашел ошибку в коде с обработкой заказов наличными версия должна стать 0.2.3?
И последнее: все фичи внедрены и отлажены образовалась скажем версия 0.X.YY могу ли я скажем через какой-то срок например год( или как выбрать этот срок?) указать версию 1.0.0?
Для реализации работы с версиями планирую написать класс Version который будет иметь 4 метода
toString(), и isLess, isMore, equals(). Спасибо, интересно ваше мнение.
Здравствуйте, D.Lans, Вы писали:
DL>Взгляните: DL>http://semver.org/
Вы используете?
Перешел по ссылке.
Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать:
МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
ПО, использующее Семантическое Версионирование, должно объявить публичный API. Этот API может быть объявлен самим кодом или существовать строго в документации. Как бы ни было это сделано, он должен быть точным и исчерпывающим.
У меня небольшая программа,которая принимает данные с одной системы выбивает чеки и передает в другую систему, что в ней является публичным API?
Здравствуйте, Mamut, Вы писали:
L>>У меня небольшая программа,которая принимает данные с одной системы выбивает чеки и передает в другую систему, что в ней является публичным API?
M>Выделенное.
Извините, не совсем правильно написал. У меня небольшая программа под андроид, которая принимает данные из одной системы (заказы), производит на основе них другие (чеки) сохраняет их в своей
БД на sqlite, печатает на фискальном регистраторе и передает на обработку в другую систему. Что здесь инициатором всех действий является моя программа, сама забирает, сама производит, сама передает. Что здесь публичное API? Спасибо.
Ну вот смотри сам: L> У меня небольшая программа под андроид, которая: L> — принимает данные из одной системы (заказы), L> — производит на основе них другие (чеки) L> — сохраняет их в своей БД на sqlite, L> — печатает на фискальном регистраторе и L> — передает на обработку в другую систему.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, lvlsynaps,
V_S>Ну вот смотри сам: L>> У меня небольшая программа под андроид, которая: L>> — принимает данные из одной системы (заказы), L>> — производит на основе них другие (чеки) L>> — сохраняет их в своей БД на sqlite, L>> — печатает на фискальном регистраторе и L>> — передает на обработку в другую систему.
Т.е. API — в моем случае это "принимает данные из одной системы" и "передает на обработку в другую систему" так получается?
А что делать если программа с другими системами не взаимодействует, то получается эта система версионирования не подходит?
заметь, что это два разных API для взаимодействия с двумя разными системами.
А в общем случае версионирование — достаточно условная вещь, ты можешь поменять мажорную версию программы даже в том случае, если изменилась архитектура или интерфейс взаимодействия каких-то подсистем "под капотом" программы, причем внешнему наблюдателю это может быть даже и не заметно. Разумеется, и минорную тоже.
Вот, например, текущая версия FF — уже 40.0.2.
Здравствуйте, lvlsynaps, Вы писали:
>Вы используете?
Опосредованно.
L>Здравствуйте, Vlad_SP, Вы писали:
V_S>>Здравствуйте, lvlsynaps,
V_S>>Ну вот смотри сам: L>>> У меня небольшая программа под андроид, которая: L>>> — принимает данные из одной системы (заказы), L>>> — производит на основе них другие (чеки) L>>> — сохраняет их в своей БД на sqlite, L>>> — печатает на фискальном регистраторе и L>>> — передает на обработку в другую систему.
L>Т.е. API — в моем случае это "принимает данные из одной системы" и "передает на обработку в другую систему" так получается? L>А что делать если программа с другими системами не взаимодействует, то получается эта система версионирования не подходит?
Получается, вы можете ей пользоваться, меняя только патчи и миноры и будет ваша программа в виде 0.*.* как, кстати, принято в мире юникс.
Но если в будущем ситуация изменится, вам ничего не надо будет придумывать и изобретать и тем более ломать существующую систему (что хуже всего), вы просто начнете инкрементировать мажорную составляющую
её придумал я для автоматического обновления используемых версий библиотек, где такой подход имеет вполне конкретный технический смысл. искусственно натягивать её на другие области — по моему нет резона
Здравствуйте, D.Lans, Вы писали:
DL>Получается, вы можете ей пользоваться, меняя только патчи и миноры и будет ваша программа в виде 0.*.* как, кстати, принято в мире юникс.
DL>Но если в будущем ситуация изменится, вам ничего не надо будет придумывать и изобретать и тем более ломать существующую систему (что хуже всего), вы просто начнете инкрементировать мажорную составляющую
Т.е. моя программа стала взаимодействовать с другими и я с версии скажем 0.X.Y перейду на версию 1.X.Y так что ли?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>Т.е. моя программа стала взаимодействовать с другими и я с версии скажем 0.X.Y перейду на версию 1.X.Y так что ли?
S>Просто прочитай наконец спецификацию. S>
S>4.Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
S>5.Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
S>...
S>
FAQ
>>How should I deal with revisions in the 0.y.z initial development phase?
S>The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
>>How do I know when to release 1.0.0?
S>If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
S>Куда проще-то?
Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
Здравствуйте, Dym On, Вы писали:
L>>Как мне быть в моем проекте среднего размера (15 тыс строк кода), DO>Вам для каких целей? Если для себя, то делайте как удобно. DO>Если номер версии используется в названии продукта, то там другая философия: изменение первой цифры — платное обновление лицензии, изменение второй — бесплатный апдейт, ну может быть и платный, кстати , тогда бесплатный — третья цифра. Номера версии меняются в зависимости от потока платежей, как только он иссякает, меняем первую цифру. Но это уже к программированию отношения не имеет.
Ну как сказать для себя, я программист на предприятии, просто раньше я за номер версии использовал номер ревизии из svn а тут появилось свободное время и решил может есть какие-то стандарты на этот счет чтобы не придумывать велосипед решил поискать, поспрашивать.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>обрати внимание на дату:
Подобных предложений куча была, тынц и тынц, например. GNU version numbering и pixman versioning scheme туда же.
Ну а сам three-part-number идёт с незапамятных времён, это предок стандартного 4-part, появившегося с внедрением SCM.
Проблема в том, что практически нигде дело дальше пожеланий не пошло. В хаскелле НЯП тоже.
Заслуга semver в том, что весь этот зоопарк был утрамбован в простой и однозначный стандарт с рекомендациями, FAQ и поддержкой почти всех частных случаев вплоть до текстовых меток. Ну и ещё в том, что он поспел как раз к волне хайпа на git и к отмиранию понятия "номер ревизии".
Здравствуйте, Dym On, Вы писали:
L>>Как мне быть в моем проекте среднего размера (15 тыс строк кода), DO>Вам для каких целей? Если для себя, то делайте как удобно. DO>Если номер версии используется в названии продукта, то там другая философия: изменение первой цифры — платное обновление лицензии, изменение второй — бесплатный апдейт, ну может быть и платный, кстати , тогда бесплатный — третья цифра.
Номера версии меняются в зависимости от потока платежей, как только он иссякает, меняем первую цифру. Но это уже к программированию отношения не имеет.
Вы имеете ввиду что если продукт с версией 5.0 перестали покупать то просто меняем версию на 6.0 без изменений в коде и ждем пополнения средств?
Здравствуйте, lvlsynaps, Вы писали:
L>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
Вообще-то даёт, сразу после объяснения, зачем оно вообще нужно:
В системе с множественными зависимостями выпуск новой версии может быстро превратиться в кошмар. Если спецификации зависимости слишком жесткие, вы находитесь в опасности блокирования выпуска новой версии (невозможность обновить пакет без необходимости выпуска новой версии каждой зависимой библиотеки). Если спецификация зависимостей слишком свободна, вас неизбежно настигнет версионное несоответствие (необоснованное предположение совместимости с будущими версиями).
В качестве решения данной проблемы я предлагаю простой набор правил и требований, которые определяют, как назначаются и увеличиваются номера версий. Для того чтобы эта система работала, вам необходимо определить публичный API. Он может быть описан в документации или определяться самим кодом. Главное, чтобы этот API был ясным и точным. Однажды определив публичный API, вы сообщаете об изменениях в нём особым увеличением номера версий.
Кэп намекает, что в случае, когда с софтом работает напрямую пользователь, в качестве API выступает UI. В смысле, не кнопочки и не пиксели, речь про набор возможностей и поведение программы.
Посмотрите на это дело с точки зрения it-директора. Нужно скажем, установить софт для n+1-го пользователя, вышла новая версия 1.2.4. Имеет ли смысл её ставить, если у остальных пользователей стоит 1.1.0 и обучение проводилось именно на этой версии?
В случае, если версии соответствуют semver ответ очевиден. Если нет — нет.
L>Ну как сказать для себя, я программист на предприятии, просто раньше я за номер версии использовал номер ревизии из svn а тут появилось свободное время и решил может есть какие-то стандарты на этот счет чтобы не придумывать велосипед решил поискать, поспрашивать.
Если номер версии не торчит в названии продукта на продажу сторонним покупателям и у вас нет дикомфорта в использовании номера ревизии из svn в качестве номера версии, то и менять ничего не надо (ну только если делать уж совсем нечего).
L>Вы имеете ввиду что если продукт с версией 5.0 перестали покупать то просто меняем версию на 6.0 без изменений в коде и ждем пополнения средств?
Не это. В ПО постоянно вносятся исправления, какие-то фичи добавляются, пока продажи идут хорошо, то выпускаются версии 5.1, 5.2 и т.д. Можно рассылать бесплатные апдейты. Когда продажи проседают, в какой-то момент объявляете не 5.3, а 6.0 с предложением обновить лицензию платно. Ну и в новой версии, конечно, надо иконки перерисовать .
Здравствуйте, Dym On, Вы писали:
L>>Вы имеете ввиду что если продукт с версией 5.0 перестали покупать то просто меняем версию на 6.0 без изменений в коде и ждем пополнения средств? DO>Не это. В ПО постоянно вносятся исправления, какие-то фичи добавляются, пока продажи идут хорошо, то выпускаются версии 5.1, 5.2 и т.д. Можно рассылать бесплатные апдейты. Когда продажи проседают, в какой-то момент объявляете не 5.3, а 6.0 с предложением обновить лицензию платно. Ну и в новой версии, конечно, надо иконки перерисовать .
Помоему вы более просто перефразировали про 5.3 и 6.0 и иконки т.е мы имеем ввиду одно и то же.
Здравствуйте, Dym On, Вы писали:
L>>Ну как сказать для себя, я программист на предприятии, просто раньше я за номер версии использовал номер ревизии из svn а тут появилось свободное время и решил может есть какие-то стандарты на этот счет чтобы не придумывать велосипед решил поискать, поспрашивать. DO>Если номер версии не торчит в названии продукта на продажу сторонним покупателям и у вас нет дикомфорта в использовании номера ревизии из svn в качестве номера версии, то и менять ничего не надо (ну только если делать уж совсем нечего).
Ну как сказать дискомфорт просто захотелось провентилировать этот вопрос возможно как-то причесать, ведь номер ревизии из свн имеет некоторые недостатки возможны скачки версий из-за лишних коммитов, я просто привык в конце дня делать коммит на всякий случай а на следующий день могу сделать ревер мердж и новый коммит в результате получается пропасть между версиями хотя был исправлен всего лишь один баг. Пользователям это вроде не мешает, самому неприятно.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
S>Вообще-то даёт, сразу после объяснения, зачем оно вообще нужно: S>
S>В системе с множественными зависимостями выпуск новой версии может быстро превратиться в кошмар. Если спецификации зависимости слишком жесткие, вы находитесь в опасности блокирования выпуска новой версии (невозможность обновить пакет без необходимости выпуска новой версии каждой зависимой библиотеки). Если спецификация зависимостей слишком свободна, вас неизбежно настигнет версионное несоответствие (необоснованное предположение совместимости с будущими версиями).
S>В качестве решения данной проблемы я предлагаю простой набор правил и требований, которые определяют, как назначаются и увеличиваются номера версий. Для того чтобы эта система работала, вам необходимо определить публичный API. Он может быть описан в документации или определяться самим кодом. Главное, чтобы этот API был ясным и точным. Однажды определив публичный API, вы сообщаете об изменениях в нём особым увеличением номера версий.
S>Кэп намекает, что в случае, когда с софтом работает напрямую пользователь, в качестве API выступает UI. В смысле, не кнопочки и не пиксели, речь про набор возможностей и поведение программы.
зачем тогда использовать для этого аббревиатуру API у которой уже есть четкое определение, если эта спецификация дает для нее такие плавающие рамки, и каждый сам решать что такое API может действительно эта система больше для библиотек подходит?
S>Посмотрите на это дело с точки зрения it-директора. Нужно скажем, установить софт для n+1-го пользователя, вышла новая версия 1.2.4. Имеет ли смысл её ставить, если у остальных пользователей стоит 1.1.0 и обучение проводилось именно на этой версии?
S>В случае, если версии соответствуют semver ответ очевиден. Если нет — нет.
Здравствуйте, lvlsynaps, Вы писали:
L>зачем тогда использовать для этого аббревиатуру API у которой уже есть четкое определение, если эта спецификация дает для нее такие плавающие рамки, и каждый сам решать что такое API может действительно эта система больше для библиотек подходит?
Ну так способ нумерации в semver заточен в первую очередь на разруливание зависимостей библиотек/пакетов.
Для других задач его никто не запрещает использовать, провести аналогию API <-> UI как бы несложно
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>зачем тогда использовать для этого аббревиатуру API у которой уже есть четкое определение, если эта спецификация дает для нее такие плавающие рамки, и каждый сам решать что такое API может действительно эта система больше для библиотек подходит?
S>Ну так способ нумерации в semver заточен в первую очередь на разруливание зависимостей библиотек/пакетов. S>Для других задач его никто не запрещает использовать, провести аналогию API <-> UI как бы несложно
Слушай, можешь привести простой пример работы данной системы как он изначально задуман для каких нибудь выдуманных программ?
Здравствуйте, lvlsynaps, Вы писали:
L>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
Если посмотреть на ситуацию под другим углом, то можно считать, что это не программа стягивает, а в программу засовывают. И тогда изменение формата засовываемых в нее данных будет фактическим изменением публичного API.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, lvlsynaps, Вы писали:
L>Слушай, можешь привести простой пример работы данной системы как он изначально задуман для каких нибудь выдуманных программ?
Не вопрос На примере той же студии:
VS 2015 - 14.0.0
VS 2015 + хотфикс - 14.0.123
VS 2015 update 1 - 14.1.0
VS 2017 - 15.0.0
решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>Слушай, можешь привести простой пример работы данной системы как он изначально задуман для каких нибудь выдуманных программ?
S>Не вопрос На примере той же студии: S>
S>решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org.
Ну подожди я просил как изначально задуман семвер , ведь VS это не библиотека а IDE самостоятельная программа какой публичный API она объявляет?
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, lvlsynaps, Вы писали:
L>>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
Н>Если посмотреть на ситуацию под другим углом, то можно считать, что это не программа стягивает, а в программу засовывают. И тогда изменение формата засовываемых в нее данных будет фактическим изменением публичного API.
Да можно и так посмотреть, а вот другой случай конкретно мой: программа затягивает данные из одной системы генерирует другие на основе их и передает в другую систему. Но при этом это не библиотека а самостоятельный проект, который использует библиотеки но самое важное что проект с другими системами не может быть использован т.к их нет и не планируется.
Здравствуйте, lvlsynaps, Вы писали:
S>>решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org. L>Ну подожди я просил как изначально задуман семвер , ведь VS это не библиотека а IDE самостоятельная программа какой публичный API она объявляет?
Давай так: определись сам, какой ответ ты хочешь услышать, сравни с текстом на semver.org и определись, подходит оно тебе или нет.
Копировать цитаты и объяснять смысл фразы "использовать с умом" как-то надоело
Ладно один-два раза. Но обсждение на две страницы из-за того, что лень прочитать спецификацию | поискать "semver desktop versioning" — это перебор
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
S>>>решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org. L>>Ну подожди я просил как изначально задуман семвер , ведь VS это не библиотека а IDE самостоятельная программа какой публичный API она объявляет?
S>Давай так: определись сам, какой ответ ты хочешь услышать, сравни с текстом на semver.org и определись, подходит оно тебе или нет. S>Копировать цитаты и объяснять смысл фразы "использовать с умом" как-то надоело
S>Ладно один-два раза. Но обсждение на две страницы из-за того, что лень прочитать спецификацию | поискать "semver desktop versioning" — это перебор
S>Тем более что вопрос обсуждался неоднократно и ответы везде совпадают: S>http://programmers.stackexchange.com/questions/255190/how-does-semantic-versioning-apply-to-programs-without-api S>http://programmers.stackexchange.com/questions/200002/semantic-versioning-for-desktop-applications
Я хочу понять на примере для чего создан семвер и в чем его сильные стороны, потому что для десктопных приложений это натягивание.
Здравствуйте, lvlsynaps, Вы писали: L>Да можно и так посмотреть, а вот другой случай конкретно мой: программа затягивает данные из одной системы генерирует другие на основе их и передает в другую систему.
Что будет, когда формат данных в одной из систем поменяется?
Например, если вы тянете данные напрямую из СУБД, и поменялась структура таблиц.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Заслуга semver в том, что весь этот зоопарк был утрамбован в простой и однозначный стандарт с рекомендациями, FAQ и поддержкой почти всех частных случаев вплоть до текстовых меток. Ну и ещё в том, что он поспел как раз к волне хайпа на git и к отмиранию понятия "номер ревизии".
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
SemVer, просто подходит его автору и его видению мира, а в нормальном понимании версий — это ерунда, потому, что разный софт традиционно версионируится по разному. OpenSSL к примеру 1.0.2d. Во-вторых, эта вся семантика-романтика — не учитывает природу и натуру софта и/или целевого использования. Скажем, если мы говорим о семантике и совместимости API на уровне исходных кодов или бинарных сборок? Потому, что, изменившиеся зависимости — должны пораждать новые версии продуктов, вне зависимости от того меняют они API или нет. При чём, иногда изменение некоторых зависимостей — должны порождать новые мажорные версии, при этом надо ещё как-то конечным пользователям донести и свой версию своего контракта (API). Есть и случаи, когда софт собирается под кастомера, и тут скорее всего хоть и будет базовая A.B.C — но остальная номенклатура будет зависить от внутреннего процесса (рассматривать это как отдельный продукт, или как суб-продукт). В общем, есть тысяча точек вращения, и semver не подходит для всего, хотя в него вписывается и многое.
А вот ещё примеры из реальной жизни:
1. У Intel встречаются версии 15.28.24.64.4229 и 15.28.24.4229. 64 — это x64. Тем не менее они используют именно такую нумерацию.
2. OpenSSL и другие, — схема X.Y.Zp — где p — hotfix/patch после X.Y.Z.
3. Debian-like: (на примере mono) 3.2.8+dfsg-4ubuntu1.1 и 4.0.3.20-0xamarin1. Хотя бывают и более замысловатые: 2.6.3+dfsg-1~xamarin2. При этом там используется почти обычный alphanumeric формат, и исходную версию продукта никто не меняет (и большинство из них нормально влазят).
4. Ну и наконец, версия Windows не ограничивается A.B.C.D. А номер билда выглядит приблизительно так: 10525.0.amd64fre.th2_release.150812-1658.
А так да — всё просто и однозначно. Особенно если перестать использовать дурацкие псеводстандарты, которым вдобавок никто не следует.
Здравствуйте, fddima, Вы писали:
f> SemVer, просто подходит его автору и его видению мира, а в нормальном понимании версий — это ерунда, потому, что разный софт традиционно версионируится по разному.
Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
f> OpenSSL к примеру 1.0.2d. Во-вторых, эта вся семантика-романтика — не учитывает природу и натуру софта и/или целевого использования. Скажем, если мы говорим о семантике и совместимости API на уровне исходных кодов или бинарных сборок?
Исходный код обязан каждый раз порождать идентичную бинарную сборку. Поэтому — какая разница? Если не так — значит в процессе разработки бардак и нет такого понятия как reproducible build.
f> Потому, что, изменившиеся зависимости — должны пораждать новые версии продуктов, вне зависимости от того меняют они API или нет. При чём, иногда изменение некоторых зависимостей — должны порождать новые мажорные версии, при этом надо ещё как-то конечным пользователям донести и свой версию своего контракта (API).
А какая разница конечному пользователю почему изменилось поведение — из-за изменения самого кода или какой-то зависимости? И да, делаем мажорную версию, если надо.
f> Есть и случаи, когда софт собирается под кастомера, и тут скорее всего хоть и будет базовая A.B.C — но остальная номенклатура будет зависить от внутреннего процесса (рассматривать это как отдельный продукт, или как суб-продукт). В общем, есть тысяча точек вращения, и semver не подходит для всего, хотя в него вписывается и многое.
По-моему стандарт достаточно универсален, поэтому можно вписать всё.
f> А вот ещё примеры из реальной жизни: f> 1. У Intel встречаются версии 15.28.24.64.4229 и 15.28.24.4229. 64 — это x64. Тем не менее они используют именно такую нумерацию.
И что? Традиция. платформу можно положить в build metadata или в имя продукта. Ведь очевидно, что ...64... и ...86... это, очевидно, не увеличение версии.
f> 2... f> 3... f> 4...
ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
f> А так да — всё просто и однозначно. Особенно если перестать использовать дурацкие псеводстандарты, которым вдобавок никто не следует.
А что использовать-то? Каждый должен сочинять то на что горазд?
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
Повсеместное форсирование semver — не учитывает главного, — а именно, потребностей разработчика, и сложности (или простоты) софта. Или вообще назначения.
>Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
Это не стандарт, и даже не рекомендация. В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту? Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия.
f>> OpenSSL к примеру 1.0.2d. Во-вторых, эта вся семантика-романтика — не учитывает природу и натуру софта и/или целевого использования. Скажем, если мы говорим о семантике и совместимости API на уровне исходных кодов или бинарных сборок? ·>Исходный код обязан каждый раз порождать идентичную бинарную сборку. Поэтому — какая разница? Если не так — значит в процессе разработки бардак и нет такого понятия как reproducible build.
Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb.
Кроме того библиотека версии A.B.C может поставляться в 3-х упаковках: с UTF8 строками, с UTF16 строками и UTF32. Как автору библиотеки — тебе может быть фиолетово, для тебя — это всё есть A.B.C. Для потребителей артефактов — это 3 разных версии, с несовместимым ABI.
f>> Потому, что, изменившиеся зависимости — должны пораждать новые версии продуктов, вне зависимости от того меняют они API или нет. При чём, иногда изменение некоторых зависимостей — должны порождать новые мажорные версии, при этом надо ещё как-то конечным пользователям донести и свой версию своего контракта (API). ·>А какая разница конечному пользователю почему изменилось поведение — из-за изменения самого кода или какой-то зависимости? И да, делаем мажорную версию, если надо.
Тут обратная ситуация. Нам как потребителям-девелоперам всё ещё интересная версия, которая бы не была рандомным числом.
·>По-моему стандарт достаточно универсален, поэтому можно вписать всё.
За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease. Вообще в интернете если поискать есть полно критики semver.
f>> 1. У Intel встречаются версии 15.28.24.64.4229 и 15.28.24.4229. 64 — это x64. Тем не менее они используют именно такую нумерацию. ·>И что? Традиция. платформу можно положить в build metadata или в имя продукта. Ведь очевидно, что ...64... и ...86... это, очевидно, не увеличение версии.
Build metadata не являются частью версии в semver2 и из сравнения исключаются. При этом очевидно что 64 и 86 — есть весьма разные билды, которые живут параллельно -> следовательно платформу невозможно положить в build metadata. Что касатеся очевидности, то предшествование версий обеспечивается принятой схемой версионирования, и некоторые из них — очевидны. Другие нет. При этом семантика схемы — обеспечивается автором. На ручнике или с помощью тулзов. Поэтому кроме как говорить о возможной рекомендации — не приходится.
·>ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
В случае с debian — это именно версия пакета. Т.к. этот пакет собирается особым образом, наносятя патчи, конфигурируются и прочие вещи. Это позволяет пушить изменения (исправления), в том числе и секьюрити фиксы, для библиотек, базовая версия которых к тому моменту — не изменилась. Вместе с тем, это не параллельное версионирование. Это больше похоже на бранч.
f>> А так да — всё просто и однозначно. Особенно если перестать использовать дурацкие псеводстандарты, которым вдобавок никто не следует. ·>А что использовать-то? Каждый должен сочинять то на что горазд?
Ещё раз — semver пихать куда не попадя — не нужно.
Для продуктов может быть достаточно A.B. Для библиотек A.B.C, мы всё равно все к этом привыкли. Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость.
Короче говоря — как только будете заниматься маппингом технологических версий на внешние, только лишь для того, что бы угодить тулзам, которые с другими схемами версий не работают — тогда станет всё понятно.
Здравствуйте, ·, Вы писали:
·> ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
Это отличается потому, что ты, собирая свой продукт, будешь добавлять зависимость mono версии "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2", а дальше package manager сам разберётся что делать с этими +-~.
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
·>Так натягивается же.
Я показал где он не подходит. Но его всё равно упорно натягивают.
f>> Повсеместное форсирование semver — не учитывает главного, — а именно, потребностей разработчика, и сложности (или простоты) софта. Или вообще назначения. ·>Учитывает достаточно чтобы покрыть и сложный (не путаем с переусложнённым), и простой софт.
Технологии не должны следовать правилу 80/20 или good enough. Технологии должны давать так много, как только могут. В противном случае, они быстро морально устаревают.
f>> >Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт. f>> Это не стандарт, и даже не рекомендация. ·>Спецификация, набор правил, соглашение. Какая разница?
Разница только в том, что ничем не обоснованные ограничения semver2 энфорсят куда не попадя.
А ответственность (семантичность) формируемых автором версий — лежит на его плечах, и от схемы версионирования никак не зависит.
Таким образом автор всё равно должен декларировать, какой семантики он собирается придерживаться.
f>> В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту? ·>Плохая аналогия. Не надо путать культурные ценности и инженерную дисциплину.
Отличная аналогия, в программировании — есть свои культурные ценности.
f>> Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия. ·>Зачем у тебя в розетке 220 вольт? Ведь нет никакой необходимости, и 22, и 2200 — точно такие же вольты.
О как. А как же так, что ещё используется 110? "Ведь нет никакой необходимости."
f>> Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb. ·>Бардак, что ещё сказать... У нас нет "установленного софта". Точная версия jdk, python, и прочего явно указана в исходном коде.
Это не бардак, а объективная реальность. Не весь софт ставится side-by-side. А "reproducible" будет ограничена только тем, что выданы будут похожие бинарники. Максимально близкие — да, но не более.
f>> Кроме того библиотека версии A.B.C может поставляться в 3-х упаковках: с UTF8 строками, с UTF16 строками и UTF32. Как автору библиотеки — тебе может быть фиолетово, для тебя — это всё есть A.B.C. Для потребителей артефактов — это 3 разных версии, с несовместимым ABI. ·>Для потребителей это три разных библиотеки. Потребитель скорее всего будет использовать одну из них (или так же делать три упаковки) и отслеживать изменения именно "A.B.C".
Именно. И если автор публикует их все 3 сразу — они должны идентифицироваться каким-то образом.
f>> ·>По-моему стандарт достаточно универсален, поэтому можно вписать всё. f>> За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease. ·>А какой смысл вложен в этот postrelease? Почему нельзя сделать A.B.(C+1)?
Потому что A.B.(C+1) уже опубликован.
f>> Вообще в интернете если поискать есть полно критики semver. ·>Я нашел два: ·>1. Effort is required to do the right thing ·>2. This will be an ongoing effort until downstream projects adopt Semantic Versioning. ·>Хех...
В гугле забанили? Ну вот одно из более-менее внятных личных мнений: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e . https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249 . http://sentimentalversioning.org/ .
В конце концов есть и historical-based схемы, которые так же используются (хотя они и не будут так удобны).
f>> Build metadata не являются частью версии в semver2 и из сравнения исключаются. ·>И правильно что исключаются. Сравнение нужно для чего? Для того, чтобы принять решение — нужно ли обновление версии или нет и оценить сложность. Я вот помню уже попадал на такую граблю, когда выбирал последний релиз смотря на строки типа "15.28.24.64.4229", "15.28.24.64.4532", "15.28.24.86.4532" .
Каким образом тогда 1.0.0+x86 и 1.0.0+x64 будут различимы? Вообще архитектура — это так же часть версии артефакта, однако никакого предшествования тут быть не может, и они естественно должны обрабатываться специальным образом. (Т.е. выбираем правильный пакет, в зависимости от таргета или рантайма).
f>> При этом очевидно что 64 и 86 — есть весьма разные билды, которые живут параллельно -> следовательно платформу невозможно положить в build metadata. Что касатеся очевидности, то предшествование версий обеспечивается принятой схемой версионирования, и некоторые из них — очевидны. Другие нет. При этом семантика схемы — обеспечивается автором. На ручнике или с помощью тулзов. Поэтому кроме как говорить о возможной рекомендации — не приходится. ·>Но уж точно платформу нельзя класть в значимый номер версии.
Выше написал — не согалсен.
·>Понятно, конечно, что можно делать. Но это вовсе не значит, что так нужно делать.
Выше написал. То как это у Intel — по дурацки, я и не спорю. Вопрос лишь в том, что если им удобно именно так — отлично. Это называется схемой версионирования. Они имеют свою идентификацию по своим правилам. Вот и всё. Другое дело, что с этими версиями мало что сделаешь, т.к. они в разных плоскостях и реально ни один специально не написанный тулинг с этим правильно работать не будет.
f>> В случае с debian — это именно версия пакета. Т.к. этот пакет собирается особым образом, наносятя патчи, конфигурируются и прочие вещи. Это позволяет пушить изменения (исправления), в том числе и секьюрити фиксы, для библиотек, базовая версия которых к тому моменту — не изменилась. Вместе с тем, это не параллельное версионирование. Это больше похоже на бранч. ·>А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю?
В большинстве случаев да. Но ты волен прописать и полную версию.
f>> Ещё раз — semver пихать куда не попадя — не нужно. f>> Для продуктов может быть достаточно A.B. Для библиотек A.B.C, мы всё равно все к этом привыкли. ·>Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться.
Ввиду той самой "reproducible build" — софт один хрен должен ссылаться на конкретные версии. А апгрейдить зависимости — по требованию / предлагать. А для того, что бы ссылаться на любую версию (представимую ввиде строки) — вообще никакая схема версионирования не нужна. Ссылаться же на часть версии, и выбирать последнюю — это — уже соглашение и ответственность. Последствия и риски должен понимать прежде всего тот, кто ссылается не на конкретную версию, а на её часть.
f>> Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость. ·>Извини, но софтостроение — инженерная дисциплина. Там не чувствовать надо, а рационально решать.
Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах.
f>> Короче говоря — как только будете заниматься маппингом технологических версий на внешние, только лишь для того, что бы угодить тулзам, которые с другими схемами версий не работают — тогда станет всё понятно. ·>semver ничего о внешних (маркетинговых) версиях не говорит, хоть Lollipop, хоть Vista.
Зато semver много чего говорит о внутренних версиях, и вводит поняние prerelease. Кроме того тут вообще о "маркетинговых" версиях никто не говорил.
Здравствуйте, ·, Вы писали:
·>·> ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list. ·>Это отличается потому, что ты, собирая свой продукт, будешь добавлять зависимость mono версии "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2", а дальше package manager сам разберётся что делать с этими +-~.
Нет. Собирая свой продукт, ты озаботишься, что бы он собирался с правильными зависмостями, и аггрегировал правильные зависимости, а сами зависимости брались из правильных репозиториев. Соответственно — "4.0.3.20+dfsg-1~xamarin2".
Здесь вообще-то нет единого общего решения, т.к. назначение — разное.
Я опять вынужден повториться, — спецификации, рекомендации и соглашения — согласуют разработчиков. Технологии и тулзы — помогают. Не наоборот.
PS: Debian — был пример того, каким беспомощным выглядит semver, если бы его пытались натянуть на это. Другие репозитории используют другие правила, однако туда semver тоже не влезет. Вместе с тем — все модные репозитории для разработчиков (nuget, npm) — гонятся за semver, из хороших побуждений, однако игнорируют тот факт, что это механизм дистрибуции. Т.е. изначально репозиторий не может вместить себе оригинальную авторскую версию (openssl 1.0.2d), затем — непонимание разных форм упаковок/назначения (исходники, бинарники, ...). Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть. И таких точек вращения — может быть много, в том числе и те, о которых ты ничего не подозреваешь. Даже если конкретный менеджер пакетов или репозиторий имеет встроенную поддержку платформ и архитектур — какого черта версия пакета не должна этого отражать, т.е. например быть 1.3.0-win.x64 (и это релизная версия, пересечения с semver случайны)?
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
F>·>Так натягивается же. F> Я показал где он не подходит. Но его всё равно упорно натягивают.
Ты показал где он не используется. Но это не означает, что его там невозможно использовать.
f>>> >Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт. f>>> Это не стандарт, и даже не рекомендация. F>·>Спецификация, набор правил, соглашение. Какая разница? F> Разница только в том, что ничем не обоснованные ограничения semver2 энфорсят куда не попадя. F> А ответственность (семантичность) формируемых автором версий — лежит на его плечах, и от схемы версионирования никак не зависит.
Логично. Стандартная схема версирования же позволяет донести это до других, облегчить коммуникацию.
F> Таким образом автор всё равно должен декларировать, какой семантики он собирается придерживаться.
Самое разумное декларирование состоит из шести букв: "semver".
F>·>Плохая аналогия. Не надо путать культурные ценности и инженерную дисциплину. F> Отличная аналогия, в программировании — есть свои культурные ценности.
Ф топку их, как и аршины с пядями, и дюймы бы туда же. Единственная их ценность — тормозить развитие отрасли.
F>·>Зачем у тебя в розетке 220 вольт? Ведь нет никакой необходимости, и 22, и 2200 — точно такие же вольты. F> О как. А как же так, что ещё используется 110? "Ведь нет никакой необходимости."
Верно. Но, как я понимаю, в масштабах страны экономический эффект перехода с 110 к 220 в краткосрочной перспективе, скорее всего, будет отрицательный.
f>>> Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb. F>·>Бардак, что ещё сказать... У нас нет "установленного софта". Точная версия jdk, python, и прочего явно указана в исходном коде. F> Это не бардак, а объективная реальность. Не весь софт ставится side-by-side.
Это проблема софта, которую надо исправлять, а не необходимость.
F> А "reproducible" будет ограничена только тем, что выданы будут похожие бинарники. Максимально близкие — да, но не более.
Должны быть — с эквивалетным поведением, остальное — неважно.
F>·>Для потребителей это три разных библиотеки. Потребитель скорее всего будет использовать одну из них (или так же делать три упаковки) и отслеживать изменения именно "A.B.C". F> Именно. И если автор публикует их все 3 сразу — они должны идентифицироваться каким-то образом.
Правильно, пусть идентифицируются — именем файла, названием артифакта, классификаторм, arch-тегом, любым другим способом, но не пихайте это в номер версии, номер версии это не место куда можно запихать имя соседской кошки. Иначе он становится бесмысленным, случайным набором символов.
f>>> ·>По-моему стандарт достаточно универсален, поэтому можно вписать всё. f>>> За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease. F>·>А какой смысл вложен в этот postrelease? Почему нельзя сделать A.B.(C+1)? F> Потому что A.B.(C+1) уже опубликован.
Пусть A.B.(C+n). Притом A.B.(C+n) должен включать все изменения A.B.(C+n-1), иначе ад и израиль.
Что этот postrelease значит-то? Когда, кому и зачем на него апдейтится?
f>>> Вообще в интернете если поискать есть полно критики semver. F>·>Я нашел два: F>·>1. Effort is required to do the right thing F>·>2. This will be an ongoing effort until downstream projects adopt Semantic Versioning. F>·>Хех... F> В гугле забанили? Ну вот одно из более-менее внятных личных мнений: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e . F> http://sentimentalversioning.org/ .
Если ты не понял — это ирония и сарказм, ржут над "что решит автор, если он чувствует в этом необходимость".
F> https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249 .
Ну и? Иначе говоря "Effort is required to do the right thing", и, видимо, этот Effort не хотят делать, отпинываются как могут.
F> В конце концов есть и historical-based схемы, которые так же используются (хотя они и не будут так удобны).
Ф топку их.
F>·>И правильно что исключаются. Сравнение нужно для чего? Для того, чтобы принять решение — нужно ли обновление версии или нет и оценить сложность. Я вот помню уже попадал на такую граблю, когда выбирал последний релиз смотря на строки типа "15.28.24.64.4229", "15.28.24.64.4532", "15.28.24.86.4532" . F> Каким образом тогда 1.0.0+x86 и 1.0.0+x64 будут различимы? Вообще архитектура — это так же часть версии артефакта, однако никакого предшествования тут быть не может, и они естественно должны обрабатываться специальным образом. (Т.е. выбираем правильный пакет, в зависимости от таргета или рантайма).
Это часть идентификатора артифакта, но не версии. Идентификатор артифакта — многомерный, не надо пихать всё в одно измерение.
F>·>Понятно, конечно, что можно делать. Но это вовсе не значит, что так нужно делать. F> Выше написал. То как это у Intel — по дурацки, я и не спорю. Вопрос лишь в том, что если им удобно именно так — отлично. Это называется схемой версионирования. Они имеют свою идентификацию по своим правилам. Вот и всё. Другое дело, что с этими версиями мало что сделаешь, т.к. они в разных плоскостях и реально ни один специально не написанный тулинг с этим правильно работать не будет.
То что им "удобно" (а скорее всего это просто изобретение какого-нибудь идиота-менеджера, которого, надеюсь, уже уволили, но менять это сложно и не хотят тратить на это время-деньги), не означает что использование semver не будет удобнее.
F>·>А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю? F> В большинстве случаев да. Но ты волен прописать и полную версию.
Но это, как мне кажется, не рекомендуется и используется только как workaround.
F>·>Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться. F> Ввиду той самой "reproducible build" — софт один хрен должен ссылаться на конкретные версии. А апгрейдить зависимости — по требованию / предлагать.
И как предлагать-то? Предлагать апдейт "15.28.24.64.4532" до "15.28.24.86.4532"?
F> А для того, что бы ссылаться на любую версию (представимую ввиде строки) — вообще никакая схема версионирования не нужна. Ссылаться же на часть версии, и выбирать последнюю — это — уже соглашение и ответственность. Последствия и риски должен понимать прежде всего тот, кто ссылается не на конкретную версию, а на её часть.
И на совести кто релизит конкретную версию.
f>>> Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость. F>·>Извини, но софтостроение — инженерная дисциплина. Там не чувствовать надо, а рационально решать. F> Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах.
Уже прочувстовали и предложили sevmer, осталось внедрять, зачем ходить по тем же граблям?
F> Зато semver много чего говорит о внутренних версиях, и вводит поняние prerelease. Кроме того тут вообще о "маркетинговых" версиях никто не говорил.
Клёво. И правильно делает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, fddima, Вы писали:
F> Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть.
Почему? Ибо someapp-platform-archX будет зависеть именно от somelib-platform-archX разных версий. Не имеет смысл делать someapp for archX зависимой от somelib-platform-archY.
F> Даже если конкретный менеджер пакетов или репозиторий имеет встроенную поддержку платформ и архитектур — какого черта версия пакета не должна этого отражать?
Правильнее вопрос — какого чёрта _именно версия_ должна это отражать, тем более если архитектура поддерживается отдельно?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Надоел спор ради спора. Одни решили 220 вольт, другие 110. Вот и semver — ровно об этом же. В целом — хорошо, на практике не всегда это то, что нужно.
F>> Каким образом тогда 1.0.0+x86 и 1.0.0+x64 будут различимы? Вообще архитектура — это так же часть версии артефакта, однако никакого предшествования тут быть не может, и они естественно должны обрабатываться специальным образом. (Т.е. выбираем правильный пакет, в зависимости от таргета или рантайма). ·>Это часть идентификатора артифакта, но не версии. Идентификатор артифакта — многомерный, не надо пихать всё в одно измерение.
Об этом и речь. Многомерных имен файлов не бывает. Как и имен пакетов. Сегодняшние пакетные менеджеры начали использовать semver, самые модные — не дают дополнительных измерений. Какой тут уж semver. Накой хрен его совать туда где ему совершенно не место или он недостаточен?
У софта бывают и функциональные ограничения. И они важны. Поэтому версия есть версия. Что туда пихать — решает автор.
·>То что им "удобно" (а скорее всего это просто изобретение какого-нибудь идиота-менеджера, которого, надеюсь, уже уволили, но менять это сложно и не хотят тратить на это время-деньги), не означает что использование semver не будет удобнее.
У них ещё параллельная есть версия в скобочках. Инопланетяне.
F>>·>А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю? F>> В большинстве случаев да. Но ты волен прописать и полную версию. ·>Но это, как мне кажется, не рекомендуется и используется только как workaround.
Если мы хотим получать полную репродукцию — то прийдется указывать столько информации, сколько достаточно для идентификации конкретной версии, конкретного артефакта.
В контроллируемых случаях (как и с debian), и как и то, что пытается сделать semver — как раз дать понимание этих изменений. Вместе с тем, оно ничего не гарантирует.
F>>·>Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться. F>> Ввиду той самой "reproducible build" — софт один хрен должен ссылаться на конкретные версии. А апгрейдить зависимости — по требованию / предлагать. ·>И как предлагать-то? Предлагать апдейт "15.28.24.64.4532" до "15.28.24.86.4532"?
Это забота пакетного менеджера, его возможностей и совместимости. Если такую версию вдруг можно в него засунуть — то вероятно есть и ручки этим управлять. Впрочем 4532 — в данной схеме — номер билда, и без изменения A.B.C скорее всего не публикуется.
F>> А для того, что бы ссылаться на любую версию (представимую ввиде строки) — вообще никакая схема версионирования не нужна. Ссылаться же на часть версии, и выбирать последнюю — это — уже соглашение и ответственность. Последствия и риски должен понимать прежде всего тот, кто ссылается не на конкретную версию, а на её часть. ·>И на совести кто релизит конкретную версию.
На совести того кто релизит — это обеспечивать соглашение. При этом риски того, что всё в конечном продукте развалится, от того что он ссылается на неполные версии — остаются. Новые версии — всегда потенциально несут новые баги.
F>> Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах. ·>Уже прочувстовали и предложили sevmer, осталось внедрять, зачем ходить по тем же граблям?
Потому, что он в таком виде каком он есть (semver) — нахрен не нужен. Это всё тоже самое, что и традиционно используемое, только разбавленное словами из MUST/NOT, и откровенной отсебятиной по поводу пререлиз меток и их форматов.
Здравствуйте, ·, Вы писали:
F>> Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть. ·>Почему? Ибо someapp-platform-archX будет зависеть именно от somelib-platform-archX разных версий. Не имеет смысл делать someapp for archX зависимой от somelib-platform-archY.
Потому, что в таком случае необходимо вручную разрешать связи между platform/arch. Если среда выполнения или целевая платформа — windows, x64 — то тебе необходим именно этот пакет. Всё остальное тебя не интересует. Как только ты захочешь билдить под 3 платформы и 2-3 архитектуры — тебе прийдется переписывать зависимости под каждую из них. Универсального способа основанного на конвенциях — тут не будет, т.к. одни банально делают somelib-arch-platform, другие — используют разные имена платформ.
Что бы это разрешить без поддержки опять таки со стороны пакетного менеджера, создают поддержку в пакетном менеджере и используют мета-пакеты, извиняюсь, за тавтологию.
Очевидно, что это не единственное решение.
F>> Даже если конкретный менеджер пакетов или репозиторий имеет встроенную поддержку платформ и архитектур — какого черта версия пакета не должна этого отражать? ·>Правильнее вопрос — какого чёрта _именно версия_ должна это отражать, тем более если архитектура поддерживается отдельно?
Потому, что версией продукта является любая его публикация в любой форме. Выпустил 2 версии x64 и x86 — это два разных цифровых продукта.
Здравствуйте, fddima, Вы писали:
F>>> Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть. F>·>Почему? Ибо someapp-platform-archX будет зависеть именно от somelib-platform-archX разных версий. Не имеет смысл делать someapp for archX зависимой от somelib-platform-archY.
F> Потому, что в таком случае необходимо вручную разрешать связи между platform/arch. F> Если среда выполнения или целевая платформа — windows, x64 — то тебе необходим именно этот пакет. Всё остальное тебя не интересует. Как только ты захочешь билдить под 3 платформы и 2-3 архитектуры — тебе прийдется переписывать зависимости под каждую из них. Универсального способа основанного на конвенциях — тут не будет, т.к. одни банально делают somelib-arch-platform, другие — используют разные имена платформ. F> Что бы это разрешить без поддержки опять таки со стороны пакетного менеджера, создают поддержку в пакетном менеджере и используют мета-пакеты, извиняюсь, за тавтологию. F> Очевидно, что это не единственное решение.
Не понял. А альтернатива-то какая? И так, и так вручную. С т.з. указания платформы — какая разница как прописывать зависимость как "somelib, version=1.2.3-x86" или "somelib-x86, version=1.2.3"?
Зато с точки зрения [полу]автоматического апдейта — второе гораздо юзабельнее.
F> Потому, что версией продукта является любая его публикация в любой форме. Выпустил 2 версии x64 и x86 — это два разных цифровых продукта.
Да почему версией-то?!!! Частью идентификатора конкретного билда — да, но не версией!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, fddima, Вы писали:
F> Надоел спор ради спора. Одни решили 220 вольт, другие 110. Вот и semver — ровно об этом же. В целом — хорошо, на практике не всегда это то, что нужно.
Заменить всю проводку и оборудование в масштабах страны — одно, а заменить нумерацию версий — друоге. От аршинов таки избавились, надеюсь и от сентиметальных версий постепенно отойдут.
F>·>Это часть идентификатора артифакта, но не версии. Идентификатор артифакта — многомерный, не надо пихать всё в одно измерение. F> Об этом и речь. Многомерных имен файлов не бывает. Как и имен пакетов. Сегодняшние пакетные менеджеры начали использовать semver, самые модные — не дают дополнительных измерений. Какой тут уж semver. Накой хрен его совать туда где ему совершенно не место или он недостаточен? F> У софта бывают и функциональные ограничения. И они важны. Поэтому версия есть версия. Что туда пихать — решает автор.
Не понимаю — зачем. В чём необходимость-то поганить именно версию?
F>·>Но это, как мне кажется, не рекомендуется и используется только как workaround. F> Если мы хотим получать полную репродукцию — то прийдется указывать столько информации, сколько достаточно для идентификации конкретной версии, конкретного артефакта. F> В контроллируемых случаях (как и с debian), и как и то, что пытается сделать semver — как раз дать понимание этих изменений. Вместе с тем, оно ничего не гарантирует.
Это понятно. Во время сборки используются точные версии. А во время автоматизированного апдейта зависимостей можно использовать semver правила.
F>·>И как предлагать-то? Предлагать апдейт "15.28.24.64.4532" до "15.28.24.86.4532"? F> Это забота пакетного менеджера, его возможностей и совместимости. Если такую версию вдруг можно в него засунуть — то вероятно есть и ручки этим управлять. Впрочем 4532 — в данной схеме — номер билда, и без изменения A.B.C скорее всего не публикуется.
Т.е. правильный путь это к каждой зависимости писать специальный телепатический плагин, определяющий правила, которые чувствует автор. Так что-ли? Или таки пинать авторов, чтобы они натягивали semver в их уникальное чувствование мира?
F>>> Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах. F>·>Уже прочувстовали и предложили sevmer, осталось внедрять, зачем ходить по тем же граблям? F> Потому, что он в таком виде каком он есть (semver) — нахрен не нужен. Это всё тоже самое, что и традиционно используемое, только разбавленное словами из MUST/NOT, и откровенной отсебятиной по поводу пререлиз меток и их форматов.
А что нужно-то? Отрицая — предлагай.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
, тогда бесплатный — третья цифра. Номера версии меняются в зависимости от потока платежей, как только он иссякает, меняем первую цифру. Но это уже к программированию отношения не имеет.
В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту? 
Инопланетяне.