Здравствуйте, Somescout, Вы писали:

S>·>Де-факто — да, если цель не выпендриться достижениями отдела маркетинга.
S>Не соглашусь: это удобно, если имеем дело с api, но, к примеру, есть у нас одна постоянно меняющаяся софтина, и меня слегка достало отслеживать её версии — помнить что и когда вышло, насколько старая конкретно эта версия версия очень не удобно с semver. Поэтому эмпирически пришёл к версии в формате yyyy.mm — год и месяц релиза.
И что тебе даёт знание "когда вышло"? Ну вышло, допустим, вчера, а у меня позавчерашняя версия. И чё?

S> Просто, удобно, наглядно: видишь 2016.10, а текущая 2017.02 — сразу ясно что и насколько устарело. Само собой это не универсальный способ, но во многих случаях удобнее semver.
Только если ты в курсе процесса разработки, знаешь сколько человек и как работают над продуктом и другими проектами, у кого какие отпуска и праздники, то ты ещё можешь как-то неявно, подсознательно оценить "что и насколько устарело". Поэтому, если ты член команды, тебе кажется, что даты в качестве версий — отличная идея, для остальных — ничего не говорящие цифры, часто ещё и запутывающие. Но в общем случае — даты выпуска ни о чём не говорят. А уж в хоть сколько-то более сложном случае, когда, например, у продукта есть несколько активных версий, то эти даты будут только сбивать с толку.

Здравствуйте, ·, Вы писали:

·>И что тебе даёт знание "когда вышло"? Ну вышло, допустим, вчера, а у меня позавчерашняя версия. И чё?

Есть, к примеру firefox 3.5.4 и chrome 37. Насколько они устарели? Можно ли ими сейчас пользоваться, или они уже половину сайтов не откроют? (FYI: это просто пример, цифры версий взяты наугад).

·>Только если ты в курсе процесса разработки, знаешь сколько человек и как работают над продуктом и другими проектами, у кого какие отпуска и праздники, то ты ещё можешь как-то неявно, подсознательно оценить "что и насколько устарело". Поэтому, если ты член команды, тебе кажется, что даты в качестве версий — отличная идея, для остальных — ничего не говорящие цифры, часто ещё и запутывающие. Но в общем случае — даты выпуска ни о чём не говорят. А уж в хоть сколько-то более сложном случае, когда, например, у продукта есть несколько активных версий, то эти даты будут только сбивать с толку.

А при чём тут процесс разработки? Внутренние версии разработчики могут именовать как угодно, речь именно о нумерации релизов.

И да, как ни крути, но дата значит хоть что-то, а вот абстрактные цифры версий — вообще бессмысленны вне api.

Здравствуйте, Somescout, Вы писали:

S>·>И что тебе даёт знание "когда вышло"? Ну вышло, допустим, вчера, а у меня позавчерашняя версия. И чё?
S>Есть, к примеру firefox 3.5.4 и chrome 37. Насколько они устарели?
Надо узнать какие сейчас последние версии. И если версия 3.9.55 — то значит я без проблем могу проапгрейдиться, практически незадумываясь, прямо сейчас. А если 4.0.0, то могу ожидать, что какие-то плагины/аддоны могут не запуститься, поэтому я отложу апгрейд до выходных, когда не очень занят. А вообще с браузерами выбора особо нет, т.к. там постоянно дыры латают, надо всегда иметь последнюю версию.

S>Можно ли ими сейчас пользоваться, или они уже половину сайтов не откроют? (FYI: это просто пример, цифры версий взяты наугад).
Ага, и выводы сделаны наугад.

S>·>Только если ты в курсе процесса разработки, знаешь сколько человек и как работают над продуктом и другими проектами, у кого какие отпуска и праздники, то ты ещё можешь как-то неявно, подсознательно оценить "что и насколько устарело". Поэтому, если ты член команды, тебе кажется, что даты в качестве версий — отличная идея, для остальных — ничего не говорящие цифры, часто ещё и запутывающие. Но в общем случае — даты выпуска ни о чём не говорят. А уж в хоть сколько-то более сложном случае, когда, например, у продукта есть несколько активных версий, то эти даты будут только сбивать с толку.
S>А при чём тут процесс разработки? Внутренние версии разработчики могут именовать как угодно, речь именно о нумерации релизов.
Я и говорил о нумерации релизов. Но, вообще говоря, зачем придумывать две схемы нумерации внутренних и публичных версий? Так, чтобы жизнь краше была? В хорошо поставленном процессе разработки — любая внутрення версия должна быть хороша настолько, чтобы её тут же можно было зарелизить (aka always-releasable builds).

S>И да, как ни крути, но дата значит хоть что-то
Она ничего не значит вне контекста. Есть, к примеру firefox v2016.07.12 и chrome v2016.08.15. Насколько они устарели? Можно ли ими сейчас пользоваться? Сколько сайтов не заработает? Половина или больше?
Поддерживаются ли там, например, websockets?

S>, а вот абстрактные цифры версий — вообще бессмысленны вне api.
Смысл им даёт _semantic_ versioning.

Здравствуйте, ·, Вы писали:

S>>Есть, к примеру firefox 3.5.4 и chrome 37. Насколько они устарели?
·>Надо узнать какие сейчас последние версии. И если версия 3.9.55 — то значит я без проблем могу проапгрейдиться, практически незадумываясь, прямо сейчас. А если 4.0.0, то могу ожидать, что какие-то плагины/аддоны могут не запуститься, поэтому я отложу апгрейд до выходных, когда не очень занят.
Ну, то есть могут запуститься, могут не запуститься — а смысл тогда в смене мажорной версии?

S>>Можно ли ими сейчас пользоваться, или они уже половину сайтов не откроют? (FYI: это просто пример, цифры версий взяты наугад).
·>Ага, и выводы сделаны наугад.
А подробнее? Я вроде и примеры привёл когда это выгодно, а от вас только безосновательная агрессия "АаАа! SemVer абидели".

S>>А при чём тут процесс разработки? Внутренние версии разработчики могут именовать как угодно, речь именно о нумерации релизов.
·>Я и говорил о нумерации релизов. Но, вообще говоря, зачем придумывать две схемы нумерации внутренних и публичных версий? Так, чтобы жизнь краше была? В хорошо поставленном процессе разработки — любая внутрення версия должна быть хороша настолько, чтобы её тут же можно было зарелизить (aka always-releasable builds).
А нахрена клиенту знать внутреннюю нумерацию версий? Вот правда — зачем?

S>>И да, как ни крути, но дата значит хоть что-то
·>Она ничего не значит вне контекста. Есть, к примеру firefox v2016.07.12 и chrome v2016.08.15. Насколько они устарели? Можно ли ими сейчас пользоваться? Сколько сайтов не заработает? Половина или больше?
·>Поддерживаются ли там, например, websockets?
А типа по semver'у вы об этом сразу узнаете? Конкретно в этом случае ясно что устарели они почти на год — и это понятно без поиска информации о текущей версии.

S>>, а вот абстрактные цифры версий — вообще бессмысленны вне api.
·>Смысл им даёт _semantic_ versioning.
И какой смысл это даёт клиентскому продукту? Чем Software v4.3.5 лучше Software 2015 U3? Или Software 2015.07?
У второго варианта плюс в том, что сразу видно к какой серии относится продукт и какое обновление установлено, третий вариант имеет смысл когда продукт часто обновляется, а первый — хз где нужен, кроме как для api.

Здравствуйте, Somescout, Вы писали:

S>·>Надо узнать какие сейчас последние версии. И если версия 3.9.55 — то значит я без проблем могу проапгрейдиться, практически незадумываясь, прямо сейчас. А если 4.0.0, то могу ожидать, что какие-то плагины/аддоны могут не запуститься, поэтому я отложу апгрейд до выходных, когда не очень занят.
S>Ну, то есть могут запуститься, могут не запуститься — а смысл тогда в смене мажорной версии?
Смысл в том, что если мажорная версия не сменилась — значит ты ожидаешь что должны запуститься.
А если сменилась — то апгрейд более рискован.

S>>>Можно ли ими сейчас пользоваться, или они уже половину сайтов не откроют? (FYI: это просто пример, цифры версий взяты наугад).
S>·>Ага, и выводы сделаны наугад.
S>А подробнее? Я вроде и примеры привёл когда это выгодно, а от вас только безосновательная агрессия "АаАа! SemVer абидели".
Ты странные примеры привёл, с придуманными выводами. Выводы о свежести версии по датам делать можно только наугад, ничего точного сказать невозможно, что-то более точное можно сказать только если знаешь какую-то внутреннюю кухню процессов разработки. А если же используется semver, то это поддержка публично изветсного соглашения.

S>>>А при чём тут процесс разработки? Внутренние версии разработчики могут именовать как угодно, речь именно о нумерации релизов.
S>·>Я и говорил о нумерации релизов. Но, вообще говоря, зачем придумывать две схемы нумерации внутренних и публичных версий? Так, чтобы жизнь краше была? В хорошо поставленном процессе разработки — любая внутрення версия должна быть хороша настолько, чтобы её тут же можно было зарелизить (aka always-releasable builds).
S>А нахрена клиенту знать внутреннюю нумерацию версий? Вот правда — зачем?
Ты вначале на вопрос ответь — нахрена иметь два вида нумерации версий — внешнюю и внутреннюю?
Если ты имеешь в виду что надо прятать "страшную" часть типа шестизначного идентификатора билда, то semver предусматривает так называемую "build metadata", которую можно автоматически оттяпывать тулзами при приготовлении release notes и прочих маркетинговых материалов.

S>>>И да, как ни крути, но дата значит хоть что-то
S>·>Она ничего не значит вне контекста. Есть, к примеру firefox v2016.07.12 и chrome v2016.08.15. Насколько они устарели? Можно ли ими сейчас пользоваться? Сколько сайтов не заработает? Половина или больше?
S>·>Поддерживаются ли там, например, websockets?
S>А типа по semver'у вы об этом сразу узнаете?
В случае semver если у меня в данный момент версия 9.2.3, а последняя публичная 9.2.7324 (и даже пусть одна старее другой на год) — я могу точно сказать, что websockets там не появилось. Но я обязательно загляну в changelog, когда увижу 9.3.0 (и даже пусть её выпустили на пол часа позже) в надежде, что websockets таки допилили.

S>Конкретно в этом случае ясно что устарели они почти на год — и это понятно без поиска информации о текущей версии.
Ну устарели почти на год. И что? Вывод-то какой можно сделать?

S>>>, а вот абстрактные цифры версий — вообще бессмысленны вне api.
S>·>Смысл им даёт _semantic_ versioning.
S>И какой смысл это даёт клиентскому продукту? Чем Software v4.3.5 лучше Software 2015 U3? Или Software 2015.07?
S>У второго варианта плюс в том, что сразу видно к какой серии относится продукт и какое обновление установлено, третий вариант имеет смысл когда продукт часто обновляется, а первый — хз где нужен, кроме как для api.
В первом варианте видно, что относится к 4-й серии. Какая разница какой конкретно год? Что делать, если понадобится выпустить две серии продукта в один год? Что делать, одна серия продукта будет жить дольше года?

Здравствуйте, ·, Вы писали:

·>Смысл в том, что если мажорная версия не сменилась — значит ты ожидаешь что должны запуститься.
·>А если сменилась — то апгрейд более рискован.
Не запуститься может в обоих случаях, даже если semver полностью соблюдается. Полагаться в этом вопросе на него точно не стоит.

·>Ты странные примеры привёл, с придуманными выводами. Выводы о свежести версии по датам делать можно только наугад, ничего точного сказать невозможно, что-то более точное можно сказать только если знаешь какую-то внутреннюю кухню процессов разработки. А если же используется semver, то это поддержка публично изветсного соглашения.
В чём именно странность примеров? Firefox использовал semver и благополучно его забросил (что, кстати, показательно), chrome изначально semver не использовал. И в обоих этих случаях куда интереснее знать насколько устарел софт, чем тройку цифр major.minor.fix.

S>>>>А при чём тут процесс разработки? Внутренние версии разработчики могут именовать как угодно, речь именно о нумерации релизов.
S>>·>Я и говорил о нумерации релизов. Но, вообще говоря, зачем придумывать две схемы нумерации внутренних и публичных версий? Так, чтобы жизнь краше была? В хорошо поставленном процессе разработки — любая внутрення версия должна быть хороша настолько, чтобы её тут же можно было зарелизить (aka always-releasable builds).
S>>А нахрена клиенту знать внутреннюю нумерацию версий? Вот правда — зачем?
·>Ты вначале на вопрос ответь — нахрена иметь два вида нумерации версий — внешнюю и внутреннюю?
Для маркетинговых целей? Потому что покупателю обычно не упёрлось знать semver, особенно у софтины без открытого api. Кроме того софт и api могут версионироватся раздельно — т.е. в приложении (не говорю фронтенд, поскольку не обязательно используется именно такая модель) появляются новые фичи, но api не меняется, и наоборот — приложение остаётся неизменным а в api появляются новые возможности.

S>>А типа по semver'у вы об этом сразу узнаете?
·>В случае semver если у меня в данный момент версия 9.2.3, а последняя публичная 9.2.7324 (и даже пусть одна старее другой на год) — я могу точно сказать, что websockets там не появилось. Но я обязательно загляну в changelog, когда увижу 9.3.0 (и даже пусть её выпустили на пол часа позже) в надежде, что websockets таки допилили.
А я посмотрю что установленная версия выпущена в прошлом месяце, и даже не полезу проверять новую, сэкономив время.

S>>Конкретно в этом случае ясно что устарели они почти на год — и это понятно без поиска информации о текущей версии.
·>Ну устарели почти на год. И что? Вывод-то какой можно сделать?
Что за год они вполне могли допилить.

S>>И какой смысл это даёт клиентскому продукту? Чем Software v4.3.5 лучше Software 2015 U3? Или Software 2015.07?
S>>У второго варианта плюс в том, что сразу видно к какой серии относится продукт и какое обновление установлено, третий вариант имеет смысл когда продукт часто обновляется, а первый — хз где нужен, кроме как для api.
·>В первом варианте видно, что относится к 4-й серии.
И что?
·>Какая разница какой конкретно год?
А какая разница, что четвёртая серия? Вот есть, к примеру, PHPStorm (который, кстати, тоже послал semver) — я когда-то купил, по-моему 7 версию. Выходила 8,9 — а с моей точки зрения все апдейты в них тянули на минорные. И вот какой сакральный смысл мажорной версии и семвера вообще в таком продукте? Они не переписывают его с нуля, не добавляют грандиозных фич. Может совместимость api меняется, но мне до этого что?

Где вообще в проекте (а не api) можно объективно поставить точку, и сказать что дальше идёт новая мажорная версия? Мне приходит в голову только ситуация, когда полностью изменилась концепция работы программы — но в этом случае, возможно, уже стоит подумать о смене имени? А в прочих случаях это скорее всего будет определяться маркетингом, а не какими-либо объективными причинами.

·>Что делать, если понадобится выпустить две серии продукта в один год? Что делать, одна серия продукта будет жить дольше года?
Пусть живёт. В моём примере речь шла о постоянно обновляемых софтинах, и для них формата yyyy.MM хватит за глаза. А если уж вышел хотфикс сразу после релиза, можно и третью цифру добавить. Если же речь о долгоживущих (Software 2015 u3) — то откуда там будет множество релизов в год?

Здравствуйте, Somescout, Вы писали:

S>·>Смысл в том, что если мажорная версия не сменилась — значит ты ожидаешь что должны запуститься.
S>·>А если сменилась — то апгрейд более рискован.
S>Не запуститься может в обоих случаях, даже если semver полностью соблюдается. Полагаться в этом вопросе на него точно не стоит.
Нет, такое может быть только резульатом ошибки. Если не запустится — можно смело репортить баг.

S>·>Ты странные примеры привёл, с придуманными выводами. Выводы о свежести версии по датам делать можно только наугад, ничего точного сказать невозможно, что-то более точное можно сказать только если знаешь какую-то внутреннюю кухню процессов разработки. А если же используется semver, то это поддержка публично изветсного соглашения.
S>В чём именно странность примеров? Firefox использовал semver и благополучно его забросил (что, кстати, показательно),
Да вроде ничего принципиально отличного от semver я не наблюдаю. А если учесть, что ff родился до semver, semver как мне кажется был вдохновлён ff (что, кстати, показательно).

S>chrome изначально semver не использовал. И в обоих этих случаях куда интереснее знать насколько устарел софт, чем тройку цифр major.minor.fix.
Не знаю, схема очень на semver смахивает. Правда они почти всегда инкремируют major версию, что, кстати, не противоречит semver.

S>·>Ты вначале на вопрос ответь — нахрена иметь два вида нумерации версий — внешнюю и внутреннюю?
S>Для маркетинговых целей?
А про это я сразу сказал: "если цель не выпендриться достижениями отдела маркетинга".

S>Потому что покупателю обычно не упёрлось знать semver, особенно у софтины без открытого api.
Даже если конечному юзеру и пофиг, то бывают ещё сисадмины, которые должны этого конечного юзера обслуживать и накатывать апдейты. Хотя у админов работы и так мало, пусть изучают фантазии маркетологов каждого продукта, чтоб уж совсем от безделия не страдали.

S>Кроме того софт и api могут версионироватся раздельно — т.е. в приложении (не говорю фронтенд, поскольку не обязательно используется именно такая модель) появляются новые фичи, но api не меняется, и наоборот — приложение остаётся неизменным а в api появляются новые возможности.
Маркетинговая версия это вообще не версия, а так, текстовое имя продукта. Там версии хоть как называй, и вообще нафиг не нужны. Froyo Uniform Cupcake KitKat...

S>>>А типа по semver'у вы об этом сразу узнаете?
S>·>В случае semver если у меня в данный момент версия 9.2.3, а последняя публичная 9.2.7324 (и даже пусть одна старее другой на год) — я могу точно сказать, что websockets там не появилось. Но я обязательно загляну в changelog, когда увижу 9.3.0 (и даже пусть её выпустили на пол часа позже) в надежде, что websockets таки допилили.
S>А я посмотрю что установленная версия выпущена в прошлом месяце,
А почему именно "месяце"? А не тысячелетии или наносекунде? Берём произвольные данные — получаем произвольный результат... ну-ну, очень инжененрный подход.

S>и даже не полезу проверять новую, сэкономив время.
И фиг с ними, с CVE этими, ботнетам тоже хочется жить.

S>>>Конкретно в этом случае ясно что устарели они почти на год — и это понятно без поиска информации о текущей версии.
S>·>Ну устарели почти на год. И что? Вывод-то какой можно сделать?
S>Что за год они вполне могли допилить.
Тут ведь как: а могли и не допилить. Т.е. информации — ноль, играем в угадайку.

S>>>И какой смысл это даёт клиентскому продукту? Чем Software v4.3.5 лучше Software 2015 U3? Или Software 2015.07?
S>>>У второго варианта плюс в том, что сразу видно к какой серии относится продукт и какое обновление установлено, третий вариант имеет смысл когда продукт часто обновляется, а первый — хз где нужен, кроме как для api.
S>·>В первом варианте видно, что относится к 4-й серии.
S>И что?
Как что? Ровно то же: "сразу видно к какой серии относится продукт и какое обновление установлено".

S>·>Какая разница какой конкретно год?
S>А какая разница, что четвёртая серия? Вот есть, к примеру, PHPStorm (который, кстати, тоже послал semver) — я когда-то купил, по-моему 7 версию. Выходила 8,9 — а с моей точки зрения все апдейты в них тянули на минорные. И вот какой сакральный смысл мажорной версии и семвера вообще в таком продукте? Они не переписывают его с нуля, не добавляют грандиозных фич. Может совместимость api меняется, но мне до этого что?
Если я правильно помню, то мажорная версия у них означает как минимум несовместимость по лицензионному ключу.

S>Где вообще в проекте (а не api) можно объективно поставить точку, и сказать что дальше идёт новая мажорная версия? Мне приходит в голову только ситуация, когда полностью изменилась концепция работы программы — но в этом случае, возможно, уже стоит подумать о смене имени? А в прочих случаях это скорее всего будет определяться маркетингом, а не какими-либо объективными причинами.
Нет, когда появились несовместимые изменения.

S>·>Что делать, если понадобится выпустить две серии продукта в один год? Что делать, одна серия продукта будет жить дольше года?
S>Пусть живёт. В моём примере речь шла о постоянно обновляемых софтинах, и для них формата yyyy.MM хватит за глаза.
А если ВНЕЗАПНО не хватит — ну в маркетинге хорошие фантазёры сидят, что-нибудь придумают.

S>А если уж вышел хотфикс сразу после релиза, можно и третью цифру добавить. Если же речь о долгоживущих (Software 2015 u3) — то откуда там будет множество релизов в год?
Вопрос на засыпку: версии MSSQL 2005 в каком году выходили?
Но ладно, шучу, слава богу, что 2005 это просто маркетинговое имя, внутренние версии в принципе semver практически.

Здравствуйте, ·, Вы писали:

S>>Не запуститься может в обоих случаях, даже если semver полностью соблюдается. Полагаться в этом вопросе на него точно не стоит.
·>Нет, такое может быть только резульатом ошибки. Если не запустится — можно смело репортить баг.
Это может быть результатом исправления ошибки, на которую полагался клиент.
О, кстати, пример того как можно поломать совместимость фиксом: мне тут в соседней теме про сквид напомнили — они при переходе на 4 версию сломали авторизацию (для имён пользователей, содержащих пробел) и отказываются чинить мотивируя тем, что на самом деле они исправили ошибку, благодаря которой это работало в 3 версии.

·>Да вроде ничего принципиально отличного от semver я не наблюдаю. А если учесть, что ff родился до semver, semver как мне кажется был вдохновлён ff (что, кстати, показательно).
·>Не знаю, схема очень на semver смахивает. Правда они почти всегда инкремируют major версию, что, кстати, не противоречит semver.
Мой вариант тогда тоже от semver не отличается, за исколючением того что major-компонент начинается не с нуля.

·>Даже если конечному юзеру и пофиг, то бывают ещё сисадмины, которые должны этого конечного юзера обслуживать и накатывать апдейты. Хотя у админов работы и так мало, пусть изучают фантазии маркетологов каждого продукта, чтоб уж совсем от безделия не страдали.
Бывают сисадмины, согласен. И сисадминам на semver положить ещё больше, чем юзерам — потому что любой софт перед деплоем тестируется, даже если там билд поменялся. С другой стороны, когда такого софта несколько десятков наименований, разбираться что там наворотил отдел маркетинга с semver вообще не интересно — а вот унифицированные по дате версии софта очень полезны.

S>>Кроме того софт и api могут версионироватся раздельно — т.е. в приложении (не говорю фронтенд, поскольку не обязательно используется именно такая модель) появляются новые фичи, но api не меняется, и наоборот — приложение остаётся неизменным а в api появляются новые возможности.
·>Маркетинговая версия это вообще не версия, а так, текстовое имя продукта. Там версии хоть как называй, и вообще нафиг не нужны. Froyo Uniform Cupcake KitKat...
А при чём тут маркетинговая версия? Вот доработали api продукта, что он открывает доступ к уже имеющимя в продукте возможностям. При этом сам продукт не менялся. Версия api увеличилась, версия продукта — нет.

·>А почему именно "месяце"?
Потому что удобно. Сюрпрайз, да?

·>А не тысячелетии или наносекунде? Берём произвольные данные — получаем произвольный результат... ну-ну, очень инжененрный подход.
Что из major.minor.fix не произвольное (если речь не идёт об api)?

S>>и даже не полезу проверять новую, сэкономив время.
·>И фиг с ними, с CVE этими, ботнетам тоже хочется жить.
А при чём тут CVE? Если вы заботитесь о безопасности, вы в любом случае обновляйте до последней весии, вне зависимости от нумерации.
И, опять напомню, что изначально речь шла о постоянно обновляющейся софтине.

S>>·>В первом варианте видно, что относится к 4-й серии.
S>>И что?
·>Как что? Ровно то же: "сразу видно к какой серии относится продукт и какое обновление установлено".
А теперь смотрим на firefox, где вы не наблюдаете ничего отличного от semver. Можно, конечно, пошутить что там есть 37, 43 и 54 серии продукта.

·>Если я правильно помню, то мажорная версия у них означает как минимум несовместимость по лицензионному ключу.
То есть маркетинговый semver.

·>Нет, когда появились несовместимые изменения.
Это какие, например? Тот же Word открывает файлы созданные версиями 20-летней давности. А совместимость сверху-вниз ломается даже при минорных обновлениях.

·>А если ВНЕЗАПНО не хватит — ну в маркетинге хорошие фантазёры сидят, что-нибудь придумают.
Вы, вон, выше назвали firefox соответствующим semver. Посмотрите внимательно на его варианты версионирования на странице вики, там тоже фантазия играла. Semver, такой semver.

S>>А если уж вышел хотфикс сразу после релиза, можно и третью цифру добавить. Если же речь о долгоживущих (Software 2015 u3) — то откуда там будет множество релизов в год?
·>Вопрос на засыпку: версии MSSQL 2005 в каком году выходили?
·>Но ладно, шучу, слава богу, что 2005 это просто маркетинговое имя, внутренние версии в принципе semver практически.
Правда чтоли? И как, часто видели минорные обновления SQLServer? Изменение major.minor у них это новый продукт.

Здравствуйте, Michael7, Вы писали:

Лень искать в теме, чей именно тезис это подвтерждает, поэтому ответ на это сообщение. Тут вот чел нашел способ патчить обновления, чтобы обходить проверку процессора на вшивость: https://github.com/zeffy/kb4012218-19