Для того чтобы понять, откуда берутся ошибки реализации, можно взять типичный пример – деление на ноль. Допустим, вы решили написать программу, которая будет считать среднюю скорость роста человека (не знаю зачем, но допустим). Пользователь вводит дату своего рождения и свой рост, а программа вычитает из сегодняшнего числа дату рождения, подсчитывает ваш возраст в днях и делит рост на число ваших дней. Такая программа будет прекрасно работать для вас и ваших родственников, но если вы ее «выпустите в люди», то обязательно найдется кто-то, кто в качестве дня рождения введет сегодняшнее число. И готово – возраст ноль дней, попытка деления на ноль и программа вылетает с ошибкой. Разумеется, это самый простой пример. В реальной жизни все сложнее и зависит не только от данных, вводимых пользователем (которые можно, а точнее, нужно проверять перед использованием в программе), но и от установленных системных файлов, драйверов и кучи других вещей, предсказать которые невозможно, а их влияние на работоспособность программы – совсем не очевидно. Как правило, ошибки «первого типа» вычисляются и исправляются очень легко, в течение 10 минут. «Второй тип» – сложнее, но он затрагивает относительно небольшое число пользователей. Обычно исправление подобных ошибок приводит к изменению второй или третьей цифры в номере версии (или же, автор вообще не меняет версию, а просто выкладывает обновленный файл).
Если вы видите, что вместо версии 2.1 появилась, скажем, 2.11, то имеет смысл заглянуть на сайт программы и посмотреть, не появилось ли там описание изменений, чтобы понять, нужно оно вам или нет. Ну а если программа небольшая, то можно просто скачать обновленную версию...
Другая штука – это внесение новых функций в программу. Ведь после выхода программы автор получает какое-то количество писем от пользователей с просьбами добавить или изменить что-то в программе, советами по ее совершенствованию и тому подобное. Если много людей просят что-то одно, то автор часто прислушивается к их мнению и дописывает соответствующую функцию. Кроме того, он и сам может придумать что-то новое и интересное и встроить в программу. Обычно подобные изменения приводят к увеличению второй цифры в номере версии, то есть вместо 1.1 появляется 1.2.
Такие обновления в большинстве случаев документируются и их описание помещается в файл history.txt или WhatsNew.txt. К такой версии стоит приглядеться повнимательнее – есть большая вероятность того, что там появилось что-то такое, чего вам не хватало...
Обнаруженные ошибки или неоптимальные куски в алгоритме программы, как правило, оказываются самыми неприятными для автора, так как они требуют переписывания больших кусков кода или даже всей программы «с нуля». В то же время их исправление приносит наибольшую пользу тем, кто этой программой пользуется – значительно увеличиваются возможности программы, скорость ее работы, часто меняется внешний вид, появляется много новых функций... С другой стороны, при этом может измениться формат хранения данных, что потребует каких-то специальных действий при переходе на новую версию; может измениться название программы, ее цена и какие-то другие вещи, которые потребуют от пользователя внимательного изучения документации (что, в общем-то, никогда не мешает). Подобные «глобальные» изменения обычно приводят к увеличению первой цифры версии программы, то есть из 1.х она превращается в 2.0.