EP> Во-первых дата сборки изменится, надо ориентироваться не на номер версии EP> а на дату. Во-вторых - win-версии собирают редко, примерно раз в год.
Это как-то печально.
Рекомендую разработчикам всерьёз задуматься об этом и устроить дело так, чтобы на номер версии можно было ориентироваться, и чтобы для каждой версии собирать сборку для Windows.
Так как мне понятно, что с нуля что-то придумывать ── это не простое дело, то сразу же предлагаю просто последовать моему примеру, то есть предлагаю в этом деле (и для версии, и для сборки) такое устройство дел, которым сам пользуюсь.
Для версии ── выбирать номер по стандарту, на http://semver.org/ изложенному; вкратце говоря, номер должен состоять из трёх чисел (major.minor.patch), изменяющихся по следующим правилам:
1) Если появились изменения, исключающие обратную совместимость (то есть для работы нужно переписывать конфигурационные файлы, например), тогда число major увеличивается на единицу, а minor и patch обнуляются.
2) Если появились новинки, но обратная совместимость сохранилась (то есть для употребления новинок можно переменить конфигурационные файлы, но их старая версия сгодится для работы в прежнем режиме, например), тогда число major сохраняется, число minor увеличивается на единицу, число patch обнуляется.
3) Если новая версия содержит только исправления ошибок в программе, то есть исправления некорректного поведения её (то есть для новой версии вообще нет смысла править конфигурационные файлы, например, потому что всё будет в ней работать как прежде, только безошибочнее), тогда числа major и minor следует оставить без изменений, а число patch увеличить на единицу.
Понятно, надеюсь, что речь о конфигурационных файлах здесь только для примера: если новинки (или если несовместимые изменения) вместо конфигурационных файлов появляются, например, в параметрах запуска из командной строки, то относиться к таким новинкам (или к таким несовместимым изменениям) надо совершенно так же, и изменять соответствующее число в номере версии программы надо точно так же.
А чтобы для каждой версии делать сборку для Windows, лучше всего устроить дело таким образом, чтобы эта сборка совершалась автоматически: никому ведь не охота вручную возёхаться.
Сайт http://www.appveyor.com/ позволяет автоматически (для проектов с открытым исходным кодом ── ещё и бесплатно) совершать и сборку исходного кода в системе Windows, и прогон этой сборки через тестирование, и публикацию сборки.
Лучше всего это работает, когда исходный код лежит на Гитхабе, и на Гитхабе же настроен крючок (webhook), который дёргает AppVeyor после каждого из изменений в исходном коде, запуская автоматическую сборку и тестирование сборки. AppVeyor умеет настроить GitHub соответствующим образом.
(Я читал в документации, что вместо GitHub можно использовать BitBucket, но сам не пробовал этого.)
Сразу разъясню, что собирать и тестировать сборку лучше всего после каждого изменения в исходном коде (это позволяет отлавливать ошибки, например), а вот публиковать сборку ── далеко не после каждого, а только когда хочется именно выпустить новую версию. Для этой цели на AppVeyor существует механизм, который по адресу http://www.appveyor.com/docs/deployment#deploy-on-tag объясняется, и который публикует сборку только по случаю помечения исходного кода некоторым новым тегом на Гитхабе (обычно в таком теге указывают именно номер версии, чтоб проще отследить в дальнейшем, в каком состоянии был исходный код её). Аналога для BitBucket не существует, как я понял, потому что на сайте AppVeyor эта возможность помечена 'GitHub only'.
Пометка тегом ── не единственная возможность. Можно ведь и вообще не полагаться на автоматику AppVeyor в деле публикации сборки (и указать 'deploy: OFF' в файле конфигурации), но в скрипте сборки руками указать, что после сборки надо проверить некоторое условие и в случае чего вызвать публикатор сборки. Вот пример того, как проверяется наличие подстроки '[publish binary]' внутри commit message (внутри описания правки исходного кода) для этой цели:
Понимаю, что для достижения вышеописанного положения дел придётся исходный код перетащить на GitHub с сайта SourceForge с сохранением истории правок, то есть один раз всё же придётся повозёхаться (автоматизация этого процесса с помощью http://cvs2svn.tigris.org/cvs2git.html возможна, так что труд это не невыносимо тягостный). Возможностей на Гитхабе будет существенно больше, так что перенос пойдёт проекту на пользу.
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Давайте пройдём по кругу и кончим на Светлане Петровне. (Р. И. Хасбулатов) --- Знаешь ли ты, Eugene, что "упомянешь" _не_ пишется через "ё"? * Origin: Геленджик лежит на юге Раши, где в лесу рыдают хигураши (2:50/88)
