Воронков Василий написал что он в своих проектах использует
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?
L>У меня небольшая программа,которая принимает данные с одной системы выбивает чеки и передает в другую систему, что в ней является публичным 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 так что ли?
Здравствуйте, 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 тыс строк кода),
Вам для каких целей? Если для себя, то делайте как удобно.
Если номер версии используется в названии продукта, то там другая философия: изменение первой цифры — платное обновление лицензии, изменение второй — бесплатный апдейт, ну может быть и платный, кстати , тогда бесплатный — третья цифра. Номера версии меняются в зависимости от потока платежей, как только он иссякает, меняем первую цифру. Но это уже к программированию отношения не имеет.
Здравствуйте, Sinix, Вы писали:
S>The Semantic Versioning specification is authored by Tom Preston-Werner, inventor of Gravatars and cofounder of GitHub.
Здравствуйте, 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 ответ очевиден. Если нет — нет.
