ак известно, каждая выходящая в свет версия программы имеет свой собственный номер. Казалось бы, эта тема предельно проста и не требует дополнительных пояснений, но на некоторых аспектах вопроса о номерах версий мне все-таки хотелось бы остановиться поподробнее. Среди разработчиков программных продуктов (не только shareware) уже очень долго существует соглашение о порядке нумерации версий программ. Вы наверняка слышали о нем:
·номер версии состоит из двух частей, разделенных точкой;
·цифры до точки обозначают номер основной версии (так называемой "мажорной версии" (major version);
·1—2 цифры после точки обозначают номер вспомогательной версии (так называемой "минорной версии" (minor version)).
Изменение номера основной версии происходит при внесении в программу серьезных изменений, например, при смене интерфейса, включении новых функций, значительно повышающих возможности продукта. Если в программу были внесены небольшие изменения, то меняется первая цифра после точки; если сделанные изменения совсем уж незначительны, то меняется вторая цифра после точки.
Многие разработчики используют более сложные номера версии, учитывающие и так называемые релизы (release) и билды (build). Первый термин обозначает номер "промежуточной" версии, содержащей исправления ошибок; второй — номер перекомпиляции проекта.
Некоторые из читателей, возможно, подумают: "Как это все запутанно". И будут совершенно правы! Для многих пользователей даже такие простые номера версий, как 3.1 или 6.0, сложны для запоминания, не говоря уже о номерах типа 5.00.2614.3500.
Действительно, можете ли вы вспомнить полный номер версии браузера Internet Explorer, установленного у вас?
В 1994 году, готовя к выпуску новую, 32-разрядную версию Windows, в корпорации Microsoft решили отказаться от традиционной нумерации версий, назвав свою новую разработку не Windows 4.0, a Windows 95. Нет, "обычный" номер все равно остался (чтобы убедиться в этом, достаточно в командной строке дать команду vеr), однако он стал предназначаться для сведения опытных пользователей и специалистов. "В массы" продукт продвигался как Windows 95 — именно из-за того, что, по мнению Microsoft, традиционные номера версий не понятны большинству пользователей и запутывают их. Этот шаг оказался удачным, и корпорация Microsoft при наименовании своих продуктов продолжает пользоваться правилом, которое, перефразируя старый флотский принцип, звучит так: "Каждая версия Windows или любого другого продукта должна иметь имя собственное" — пускай даже это имя собственное выбрано в честь года выпуска программы. Windows 95 OSR, Windows 98, Windows Millennium, Windows 2000, Windows XP — в официальных названиях операционных систем линейки Microsoft Windows не встретишь традиционных "4.1" или "5.0".
Примеру Microsoft последовали другие корпорации, производящие программное обеспечение, а за ними — и некоторые shareware-разработчики программ. Особенно много было программ с индексом "98", т. к. именно в 1998 году в западных странах случился "бум" Интернета, вызвавший, в том числе, и стремительное развитие shareware-рынка. Но одновременно авторы, применившие новомодный прием, оказались в двусмысленном положении. Крупные компании, выпускавшие большие программные пакеты, обновляли свои продукты раз в один-два года, и вполне могли использовать номер соответствующего года в качестве номера версии. А для shareware-программ такой принцип нумерации версий оказался неудобен, т. к. большинство продуктов на этом рынке обновляется несколько раз в год. Для того чтобы пользователи могли отличать одну версию от другой, разработчику все равно приходилось применять традиционную систему номеров версий: 1.0, 1.01, 1.1 (например, Zet Picture Viewer 98 1.0). Но при наступлении нового года цифры "98" в названии устаревали, и приходилось менять их на "99" или "2000". После этого у пользователей возникал закономерный вопрос: "Что это — только новая версия или полностью новый продукт?" Таким образом, одновременное использование двух систем нумерации версий одного shareware-продукта еще более запутывает потребителей.
Не менее интересен и вопрос политики изменения номеров версий по мере развития shareware-продукта.
Еще со времен появления первых программ для персональных компьютеров существует пользовательский стереотип, который очень распространен и сегодня: только с версии 2.0 программа становится достойна внимания. Такое мнение выработалось в результате разочарований, которые испытывали пользователи, попробовав многочисленные программы, стремительно заполнившие рынок программного обеспечения, в том числе и shareware.
Вследствие этого я всегда рекомендую разработчикам программ как можно скорее преодолеть "барьер номера 2.0" и выпустить версию 2.0 своего продукта. Очень многие авторы программ, по моим наблюдениям, как-то даже боятся увеличивать номера версий своих программ. Типичная ситуация — они начинают отсчет номера версии не от 1.0, а от 0.00, в то время как номер версии меньше единицы традиционно воспринимается пользователями как указание на очень предварительную и "сырую" версию программы. Например, download-мепеджер FlashGet (http://www.amazesoft.coin) достаточно долго имел номер версии, меньший, чем 1.0 (0.8, 0.9 и т. д.), но при этом был качественным продуктом с обширными возможностями, развитым интерфейсом и объемной документацией. Еще один пример — разработчик, постоянно создавая новые версии с достаточно большим количеством изменений и дополнений, меняет только вторую цифру после точки, выпуская версии 1.01, 1.02, 1.03 и т. д. В результате программа, пережив выпуск уже нескольких десятков версий, имеет номер типа 1.21. А теперь представьте ситуацию: пользователь (или, например, редактор журнала, собирающий информацию для обзора shareware-продуктов), заходит на сайт online-архива программ и видит в списке два конкурирующих продукта: один, имеющий номер версии 1.21, и второй, обозначенный как 2.5. При сходстве остальных параметров этих программ (тип лицензии, размер, описание возможностей) предпочтение в большинстве случаев будет отдано второму варианту.
"Боязнь" разработчиков программ к существенному изменению номера версии обусловлена в основном тем, что они опасаются негативной реакции пользователей. На мой взгляд, это оправдано только в одном случае: автор предоставляет зарегистрированным пользователям бесплатно не все последующие версии, а только лишь minor updates, т. е. те обновления, номера версий которых изменяются в пределах цифр после точки. Например, если пользователь приобрел версию 1.2, то версии 1.3, 1.45, 1.6 и т. п. он получит бесплатно, а за версию 2.0 должен будет заплатить еще какую-то дополнительную сумму. По этой схеме распространяется, в частности, текстовый редактор UltraEdit (http://www.utlraedit.com). В этом случае при выходе версий 2.0, 3.0 и т. п. автор программы должен следить, чтобы эти версии по своим возможностям действительно сильно отличались от предыдущих, иначе пользователи будут очень недовольны тем, что их вынуждают платить за незначительные исправления. Если же зарегистрированные пользователи получают все последующие обновления бесплатно, то не нужно опасаться смены номера версии. Конечно, выпускать версию 2.0, внеся в версию 1.0 лишь небольшие изменения, не стоит. Однако и тянуть с выходом версии 2.0 (или еще хуже, 1.0), выпуская один minor update за другим, тоже не нужно. Лично я практически отказался от использования в номере версии второй цифры после точки, чтобы сделать нумерацию версий простой для запоминания пользователями, а заодно увеличить скорость перехода на более солидные номера версий.
Среди известных программных продуктов много примеров довольно смелого обращения с номерами версий. Например, Dbase II появилась "с нуля":
Dbase 1 не существовало (все из-за предубеждений пользователей относительно версий l.xx, которым якобы нельзя доверять); Microsoft Word с версии 2.0 перескочил сразу на 6.0, чтобы "унифицировать" свой номер с остальными программами пакета Microsoft Office; Netscape Navigator четвертой версии стал "шестым", чтобы хотя бы по этому параметру опередить почти вытеснившего его с рынка конкурента — Microsoft Internet Explorer. Как видите, крупные разработчики программного обеспечения в данном случае в первую очередь учитывали собственные маркетинговые интересы и не особенно комплексовали относительно предположительной реакции пользователей, что очень поучительно и для авторов shareware-программ.
WMZ: 826074280762 
Language
15.11.2007, 15:21
#1
Формирование версионности ПО
Линейный вид
