Я сейчас занимаюсь инсталлятором для новой беты... Возникла пара вопросов, ответы на которые не вполне очевидны.
1. Для FW35 + интеграции с VS2k8 и FW40 + интеграции с VS2k10 нужны два разных инсталлятора или поместить это все в один? С одной стороны, сценариев, при которых может понадобиться обе версии сразу, довольно немного и, в основном, это будет нужно только тем, кто работает над самим языком. Пользователям же это лишние мегабайты и непонятные пункты в меню custom-установки. К тому же, FW35+VS2k8 у нас вроде как релиз и пихать в тот же инсталлятор бету интеграции с VS2k10 не очень правильно. С другой стороны, будет проще прикрутить онлайн-обновления, ну и собирать сам инсталлятор.
Изначально, хотел пойти по пути одного инсталлятора, но сейчас все больше склоняюсь к тому, что разнести это дело по двум различным. Ваше мнение?
2. После миграции на Git в инсталляторе отвалилась подстановка номера ревизии в wix-проект при его сборке (осуществлялась через вызов SubWCRev). На основе этого номера также формировался новый UUID для очередной версии продукта. Пока я захардкодил туда значения руками, но хотелось бы как-то автоматизировать процесс смены UUID, версии продукта и его названия при сборке инсталлятора по исходникам новой ревизии. Проще всего сделать примитивный аналог SubWCRev, аналогичный макросу GitRevision. Но где-то тут я натыкался на мнение (по-моему Ziaw'a же) о том, что это все неправильно и надо как-то иначе.
Собственно, сейчас как раз тот момент, когда можно сделать все как-то иначе и вопрос в том, как идеологически правильно, с т.з. Git решить эту задачу?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я сейчас занимаюсь инсталлятором для новой беты... Возникла пара вопросов, ответы на которые не вполне очевидны.
KV>1. Для FW35 + интеграции с VS2k8 и FW40 + интеграции с VS2k10 нужны два разных инсталлятора или поместить это все в один? С одной стороны, сценариев, при которых может понадобиться обе версии сразу, довольно немного и, в основном, это будет нужно только тем, кто работает над самим языком. Пользователям же это лишние мегабайты и непонятные пункты в меню custom-установки. К тому же, FW35+VS2k8 у нас вроде как релиз и пихать в тот же инсталлятор бету интеграции с VS2k10 не очень правильно. С другой стороны, будет проще прикрутить онлайн-обновления, ну и собирать сам инсталлятор.
Есть еще третий вариант, который предлагал Влад: включить бинарники для FW4 на правах релиза в существующий инсталлятор, а интеграцию с VS2k10 распространять прямо в виде vsix, в который также будут включены эти бинарники (+ документация, как я понимаю), чтобы можно было ее ставить как вместе с существующим инсталлером, так и автономно, без него. У этого решения есть существенный плюс, потому что мы сможем воткнуть весь немерл и интеграцию в каталог расширений для VS2k10.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Есть еще третий вариант, который предлагал Влад: включить бинарники для FW4 на правах релиза в существующий инсталлятор, а интеграцию с VS2k10 распространять прямо в виде vsix, в который также будут включены эти бинарники (+ документация, как я понимаю), чтобы можно было ее ставить как вместе с существующим инсталлером, так и автономно, без него. У этого решения есть существенный плюс, потому что мы сможем воткнуть весь немерл и интеграцию в каталог расширений для VS2k10.
Вот это самый клевый вариант. Только я не уверен, что туда можно будет воткнуть сам немерл. Можно конечно включить нужные файлы в интеграцию и прописать Nemerle на ту папку.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я сейчас занимаюсь инсталлятором для новой беты... Возникла пара вопросов, ответы на которые не вполне очевидны.
KV>1. Для FW35 + интеграции с VS2k8 и FW40 + интеграции с VS2k10 нужны два разных инсталлятора или поместить это все в один? С одной стороны, сценариев, при которых может понадобиться обе версии сразу, довольно немного и, в основном, это будет нужно только тем, кто работает над самим языком. Пользователям же это лишние мегабайты и непонятные пункты в меню custom-установки. К тому же, FW35+VS2k8 у нас вроде как релиз и пихать в тот же инсталлятор бету интеграции с VS2k10 не очень правильно. С другой стороны, будет проще прикрутить онлайн-обновления, ну и собирать сам инсталлятор.
Если установленного фреймворка не требуется — лучше держать один инсталятор для языка и отдельные инсталяторы для интеграций (2010 вообще в галлерее должна быть).
KV>2. После миграции на Git в инсталляторе отвалилась подстановка номера ревизии в wix-проект при его сборке (осуществлялась через вызов SubWCRev). На основе этого номера также формировался новый UUID для очередной версии продукта. Пока я захардкодил туда значения руками, но хотелось бы как-то автоматизировать процесс смены UUID, версии продукта и его названия при сборке инсталлятора по исходникам новой ревизии. Проще всего сделать примитивный аналог SubWCRev,
аналогичный макросу GitRevision. Но где-то тут я натыкался на мнение (по-моему Ziaw'a же) о том, что это все неправильно и надо как-то иначе.
Мои мысли насчет контроля версий и версий сборок/инсталлятора.
Номер версии инсталятора должен задаваться просто из одного файла. Для официальных релизов его надо менять ручками, а билд инсталятора между релизами как-то метить (типа unofficial). Изменение этого файлика и оффициальный релиз надо сопровождать навешиванием тега, чтобы люди могли смотреть исходники нужной версии. Билдсервер с ночными сборками может давать свои номера, там достаточно своих механизмов.
Процесс релиза:
1. Меняем значение в файле version на 1.1RC1 (возможно туда же вбиваем новый GUID продукта, либо формириуем GUID на основе номера версии)
2. Добавляем записи в файл Changelog для новой ревизии.
3. Комитим, собираем, тестируем локально инсталляторы.
4. Ставим тег v1.1RC1 на комит и пушим.
5. Заливаем бинарники на гитхаб.
Далее, делаем ветку v1.1 от тега 1.1RC1. В эту ветку вливаем только багфиксы, никаких новых фич. Через недельку-другую, явные баги 1.1RC1 будут найдены, по их количеству и качеству надо понять, делать 1.1 или 1.1RC2. Если все ок — делаем релиз, если нашлось много всего, повторяем процедуру.
Версии сборок. В принципе можно оставить взятие их из гита, но не хотелось бы. Просто потому, что сборки теперь должны быть в гаке и ссылаться по строгому имени. Поскольку предлагается не менять публичный конртакт в процессе релиза, желательно для одной минорной версии иметь одно строгое имя, ибо править файлы проекта при переходе от 1.1RC1 к 1.1RC2 совсем не хочется.
KV>Собственно, сейчас как раз тот момент, когда можно сделать все как-то иначе и вопрос в том, как идеологически правильно, с т.з. Git решить эту задачу?
Привязка к контролю версий должна идти в другую сторону — не из VCS брать номер, а ревизию билда помечать меткой по которой можно найти исходники в VCS. Для официального билда это тег, для ночных сборок это номер сборки, по которому можно найти номер ревизии в публичном интерфейсе билдсервера. Артефакты билда никак не должны зависеть от установленных vcs и наличия самого репозитария.
P.S. Формат файла с версией надо обдумать с точки зрения удобства тулзов которым придется его юзать. Xml парсить умеют почти все.
P.P.S. К сожалению, у меня сейчас совсем мало времени, чтобы настроить всю инфраструктуру для этого самостоятельно. Я даже на работе перешел на полставки, настолько загружен другими делами. Могу только изредка и нерегулярно что-то делать. Например следить за багфиксами в master и черипикать их в релиз-кандидат. Или наоборот, если баг правился в той ветке.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я сейчас занимаюсь инсталлятором для новой беты... Возникла пара вопросов, ответы на которые не вполне очевидны.
KV>1. Для FW35 + интеграции с VS2k8 и FW40 + интеграции с VS2k10 нужны два разных инсталлятора или поместить это все в один?
По мне так лучше два разных.
KV>С одной стороны, сценариев, при которых может понадобиться обе версии сразу, довольно немного и, в основном, это будет нужно только тем, кто работает над самим языком.
Для тех кто работает над языком инсталляторы вообще не очень нужны. А уж два одновременно инсталлированных варианта, так вообще не нужно.
KV>Пользователям же это лишние мегабайты и непонятные пункты в меню custom-установки.
+1
Как временами сидящий на ЖПРС, так вообще +500.
KV>К тому же, FW35+VS2k8 у нас вроде как релиз и пихать в тот же инсталлятор бету интеграции с VS2k10 не очень правильно.
Думаю, что к релизу FW4+VS2010 нужно будет и обновленный вариант FW35+VS2k8 выпустить, так как кое что все же улучшено. Как минимум в компиляторе ряд багов поправлен. Плюс еще в интеграции кое-что доработано. Так что не смотря на разные инсталляторы, хорошо бы выпустить новые версии одновременно.
Кстати, наверно нужно по каталогам их грамотно разложить. Сделать что-то вроде:
%ProgramFiles%\Nemerle\vНомер\RuntimeНомер
KV> С другой стороны, будет проще прикрутить онлайн-обновления, ну и собирать сам инсталлятор.
+1
KV>Изначально, хотел пойти по пути одного инсталлятора, но сейчас все больше склоняюсь к тому, что разнести это дело по двум различным. Ваше мнение?
Мая согласная!
KV>2. После миграции на Git в инсталляторе отвалилась подстановка номера ревизии в wix-проект при его сборке (осуществлялась через вызов SubWCRev). На основе этого номера также формировался новый UUID для очередной версии продукта. Пока я захардкодил туда значения руками,
Плохо.
KV>но хотелось бы как-то автоматизировать процесс смены UUID, версии продукта и его названия при сборке инсталлятора по исходникам новой ревизии.
Ну, дык, за чем дело стало? Макрос есть. Нужно взять от туда код и создать плагин для генератора инсталляторов. Он ведь вроде на дотнете.
KV> Проще всего сделать примитивный аналог SubWCRev, аналогичный макросу GitRevision. Но где-то тут я натыкался на мнение (по-моему Ziaw'a же) о том, что это все неправильно и надо как-то иначе.
Ну, пусть дальше продолжает иметь это мнение. А нам нужно чтобы у нас гимора не было. Так что я поддерживаю твою идею.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Есть еще третий вариант, который предлагал Влад: включить бинарники для FW4 на правах релиза в существующий инсталлятор, а интеграцию с VS2k10 распространять прямо в виде vsix, в который также будут включены эти бинарники (+ документация, как я понимаю), чтобы можно было ее ставить как вместе с существующим инсталлером, так и автономно, без него. У этого решения есть существенный плюс, потому что мы сможем воткнуть весь немерл и интеграцию в каталог расширений для VS2k10.
Я не то чтобы предлагал именно это. Но vsix-планиг в галерее студии нужно. Как я понял там можно то ли запихать в vsix свой msi, то ли еще как-то извернутся. Надо почитать что умные люди по этому поводу пишут и сделать.
Так что я не предлагаю ничего конкретного. Я просто указываю на то, что нам нужно иметь вхождение в галерее плагинов VS 2010. Это бы способствовал популяризации. Да и удобно. Ничего искать не надо. Зашел в студию, открыл экстеншон-менеджер и набрал слово Nemerle в строке поиска.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
KV>>Есть еще третий вариант, который предлагал Влад: включить бинарники для FW4 на правах релиза в существующий инсталлятор, а интеграцию с VS2k10 распространять прямо в виде vsix, в который также будут включены эти бинарники (+ документация, как я понимаю), чтобы можно было ее ставить как вместе с существующим инсталлером, так и автономно, без него. У этого решения есть существенный плюс, потому что мы сможем воткнуть весь немерл и интеграцию в каталог расширений для VS2k10.
Z>Вот это самый клевый вариант. Только я не уверен, что туда можно будет воткнуть сам немерл. Можно конечно включить нужные файлы в интеграцию и прописать Nemerle на ту папку.
Я где-то читал, что в vsix можно воткнуть msi или что-то вроде того. В общем, это вопрос уже в ынтырнетах поднимался не раз. Надо просто изучить чужой опыт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Если установленного фреймворка не требуется — лучше держать один инсталятор для языка и отдельные инсталяторы для интеграций (2010 вообще в галлерее должна быть).
Вот это точно на фиг не нужно. 99% будет желать иметь на машине и бинарники и интеграцию. Плюс еще процентов 70 из этих 99 вообще не будет размышлять о том, что там под копотом. Они будут пытаться поставить Немерле.
Потом, интеграция все равно использует бинарники в качестве рантайма. Так что поставлять интеграцию без бинарников компилятора — это полная глупость.
Интеграция в галерее студии должна быть. Тут я полностью согласен. Но этот vsix (или что получится) дожен ставить все что нужно сам. Это будет оптимальное решение. И вроде как это возможно. Нужно только разобраться как следует.
Z>Мои мысли насчет контроля версий и версий сборок/инсталлятора.
Z>Номер версии инсталятора должен задаваться просто из одного файла. Для официальных релизов его надо менять ручками, а билд инсталятора между релизами как-то метить (типа unofficial). Изменение этого файлика и оффициальный релиз надо сопровождать навешиванием тега, чтобы люди могли смотреть исходники нужной версии. Билдсервер с ночными сборками может давать свои номера, там достаточно своих механизмов.
Это очень плохое решение. Вообще если нужно делать что-то большее чем нажатие на одну кнопку — это уже плохое решение. А задавать что-то руками — это просто пипец какое плохое решение.
Кроче на фиг. Надо делать плагин к генератору инсталляторов на подобии сабвершоновского.
Z>Процесс релиза: Z>1. Меняем значение в файле version на 1.1RC1 (возможно туда же вбиваем новый GUID продукта, либо формириуем GUID на основе номера версии) Z>2. Добавляем записи в файл Changelog для новой ревизии. Z>3. Комитим, собираем, тестируем локально инсталляторы. Z>4. Ставим тег v1.1RC1 на комит и пушим. Z>5. Заливаем бинарники на гитхаб.
У меня идея по лучше. Ставим тег. Делаем это ровно один раз. Далее выкладываем бэты по мере обновления.
Происходит это так (оптимальный вариант).
В коммите в мастер, если в подписи имеется фразу "Publish: примечание", читаем с гитхаба закрытые issue-ы и фильруем те из них что содержат теги [VS 2010] или [Compiler]. При этом отбрасываем те что помечены тегом [Nor a bug]. За тегами буду следить я. На базе issue-ов генерируем описание к релизу, а за одно и ко всем предыдущим (чтобы была история). Далее собираем все, тестируем, и если все ОК, заливаем инсталлятор куда надо.
Все это делается в автомате. Ручной труд сводится к указанию в коментарии к комиту слово Publish.
Вопрос с ветками и тегами осбуждаемый. Вопрос с ручным турдом — нет. Лучше один раз напрячся и получить правильное решение, чем потом постоянно разгребать проблемы возникшие из-за того что кто-то нарушил инструкцию или тот кто знает что нужно делать уехал (заболел, запил, женился, ...).
Z>Версии сборок. В принципе можно оставить взятие их из гита, но не хотелось бы. Просто потому, что сборки теперь должны быть в гаке и ссылаться по строгому имени. Поскольку предлагается не менять публичный конртакт в процессе релиза, желательно для одной минорной версии иметь одно строгое имя, ибо править файлы проекта при переходе от 1.1RC1 к 1.1RC2 совсем не хочется.
В файлах проекта не должно быть никаких ссылок на версии файлов. Вот и все. Гак нужен только потому что в МС какие-то безрукие товарищи не смогли по другому организовать работу КодДома для веб-проектов или еще чего-то в этом роде.
В VS 2010 все сделано очень грамотно. Даже визарды теперь находятся по простому имени.
А вот идея делать разные сборки с один номером ревизии — это очень плохая идея. Потом будет невозможно понять откуда лезут баги.
Z>Привязка к контролю версий должна идти в другую сторону — не из VCS брать номер, а ревизию билда помечать меткой по которой можно найти исходники в VCS. Для официального билда это тег, для ночных сборок это номер сборки, по которому можно найти номер ревизии в публичном интерфейсе билдсервера. Артефакты билда никак не должны зависеть от установленных vcs и наличия самого репозитария.
Вот тут согласен. Но тогда нужно как раз делать так чтобы не кто-то вручную ставил теги, а наборот, чтобы при сборке очередной версии (в основном бэт и релиз-кондитатов), процесс сборки сам ставил нужный тег. Вот это буде отличным решением!
Z>P.S. Формат файла с версией надо обдумать с точки зрения удобства тулзов которым придется его юзать. Xml парсить умеют почти все.
А что за тулзы то? Я так понял нам нужно просто сделать дотнетную сборку плагин к генератору инсталляторов (забыл как его там называют).
Z>P.P.S. К сожалению, у меня сейчас совсем мало времени, чтобы настроить всю инфраструктуру для этого самостоятельно. Я даже на работе перешел на полставки, настолько загружен другими делами. Могу только изредка и нерегулярно что-то делать. Например следить за багфиксами в master и черипикать их в релиз-кандидат. Или наоборот, если баг правился в той ветке.
Нам надо научиться брать информацию из гитхаба. Например, список issue-ов. Вот лучше помоги разобраться как это делать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это очень плохое решение. Вообще если нужно делать что-то большее чем нажатие на одну кнопку — это уже плохое решение. А задавать что-то руками — это просто пипец какое плохое решение.
релиз это релиз. его нельзя выкатить одной кнопкой, как минимум релизноутс надо писать.
VD>Кроче на фиг. Надо делать плагин к генератору инсталляторов на подобии сабвершоновского.
можно и так. только это грабли.
VD>У меня идея по лучше. Ставим тег. Делаем это ровно один раз. Далее выкладываем бэты по мере обновления.
VD>Происходит это так (оптимальный вариант).
VD>В коммите в мастер, если в подписи имеется фразу "Publish: примечание", читаем с гитхаба закрытые issue-ы и фильруем те из них что содержат теги [VS 2010] или [Compiler]. При этом отбрасываем те что помечены тегом [Nor a bug]. За тегами буду следить я. На базе issue-ов генерируем описание к релизу, а за одно и ко всем предыдущим (чтобы была история). Далее собираем все, тестируем, и если все ОК, заливаем инсталлятор куда надо.
Что пишется в releasenotes из issue? Там же бардак полный. Да и не вся работа ведется по issues, многие фичи будут потеряны.
VD>Все это делается в автомате. Ручной труд сводится к указанию в коментарии к комиту слово Publish.
Комит в репозитарий как способ дернуть билдсервер? Не назвал бы это нормальным решением, есть куча других способов.
VD>Вопрос с ветками и тегами осбуждаемый. Вопрос с ручным турдом — нет. Лучше один раз напрячся и получить правильное решение, чем потом постоянно разгребать проблемы возникшие из-за того что кто-то нарушил инструкцию или тот кто знает что нужно делать уехал (заболел, запил, женился, ...).
Я это проходил уже на своих проектах. По факту, работы по созданию и доделке фич для всего автоматом выйдет точно меньше чем релизы вручную раз в полгода. Руками надо только исправить файл с версией и дернуть билдскрипт.
Z>>Версии сборок. В принципе можно оставить взятие их из гита, но не хотелось бы. Просто потому, что сборки теперь должны быть в гаке и ссылаться по строгому имени. Поскольку предлагается не менять публичный конртакт в процессе релиза, желательно для одной минорной версии иметь одно строгое имя, ибо править файлы проекта при переходе от 1.1RC1 к 1.1RC2 совсем не хочется.
VD>В файлах проекта не должно быть никаких ссылок на версии файлов. Вот и все. Гак нужен только потому что в МС какие-то безрукие товарищи не смогли по другому организовать работу КодДома для веб-проектов или еще чего-то в этом роде.
А ты попробуй сделать ссылку на гак без версии. У меня не выходит.
VD>А вот идея делать разные сборки с один номером ревизии — это очень плохая идея. Потом будет невозможно понять откуда лезут баги.
Юзкейс непонятного бага опиши.
VD>Вот тут согласен. Но тогда нужно как раз делать так чтобы не кто-то вручную ставил теги, а наборот, чтобы при сборке очередной версии (в основном бэт и релиз-кондитатов), процесс сборки сам ставил нужный тег. Вот это буде отличным решением!
VD>А что за тулзы то? Я так понял нам нужно просто сделать дотнетную сборку плагин к генератору инсталляторов (забыл как его там называют).
Тот subrev просто генерил нужный файл по шаблону. Мне такие решения не нравятся. Впрочем вот неплохое на первый взгляд решение.
VD>Нам надо научиться брать информацию из гитхаба. Например, список issue-ов. Вот лучше помоги разобраться как это делать.
Здравствуйте, Ziaw, Вы писали:
Z>релиз это релиз. его нельзя выкатить одной кнопкой, как минимум релизноутс надо писать.
"релиз" — это слово. А на деле есть итеративный процесс состоящий из кучи выкладываний инсталлятора, тестирования, изменения и повторного выкладывания. И так до тех пор пока не появится ощущение, что продукт достиг релизного качества.
VD>>Кроче на фиг. Надо делать плагин к генератору инсталляторов на подобии сабвершоновского.
Z>можно и так. только это грабли.
Что за грабли?
Вот ручная работа — это неминуемые грабли.
Z>Что пишется в releasenotes из issue? Там же бардак полный. Да и не вся работа ведется по issues, многие фичи будут потеряны.
Там сейчас все ОК. Я разметил все issue-ы тегами. Погляди еще разок (на закрытые). По тегам можно вытянуть все что нужно.
Я потому и не хотел переливать в новый issue-треккер старый шлак.
VD>>Все это делается в автомате. Ручной труд сводится к указанию в коментарии к комиту слово Publish.
Z>Комит в репозитарий как способ дернуть билдсервер?
Именно. Но не это главное. Главное, что никакой ручной работы!
Z>Не назвал бы это нормальным решением, есть куча других способов.
Может и есть, но этот меня более чем устраивает. В прочем, предлагай, рассмотрим. Мне пофигу как дергать билдер. Главное, чтобы его можно было дернуть без особого напряга. Короче, чтобы это выглядело как нажатие на зеленую факсовую кнопку.
VD>>Вопрос с ветками и тегами осбуждаемый. Вопрос с ручным турдом — нет. Лучше один раз напрячся и получить правильное решение, чем потом постоянно разгребать проблемы возникшие из-за того что кто-то нарушил инструкцию или тот кто знает что нужно делать уехал (заболел, запил, женился, ...).
Z>Я это проходил уже на своих проектах. По факту, работы по созданию и доделке фич для всего автоматом выйдет точно меньше чем релизы вручную раз в полгода. Руками надо только исправить файл с версией и дернуть билдскрипт.
Еще раз. У нас в ближайшее время релизы будут минимум раз в неделю. А то и чаще. Людям явно тяжело собирать компилятор и интеграцию из исходинков. От того тестирование идет вяло. Мне нужно чтобы любой нюби мог взять текущую "бэту" и протестить ее.
Труд по разметке (тегами) и редактированию исьюсов я готов взять на себя (все равно за ними надо следить).
Если сделать автоматическое формирование списка изменений на базе заголовков исьюсов, то получится полный автомат.
У исьюсов, в отличи от комитов, есть человеческие идентификаторы на которые можно ссылаться. В списке изменений достаточно давать заголовок и ссылку на исьюс (где уже можно посфактом все дописывать и улучшать).
VD>>В файлах проекта не должно быть никаких ссылок на версии файлов. Вот и все. Гак нужен только потому что в МС какие-то безрукие товарищи не смогли по другому организовать работу КодДома для веб-проектов или еще чего-то в этом роде.
Z>А ты попробуй сделать ссылку на гак без версии. У меня не выходит.
Просто отметь в свойствах сборки игнорирование версии и все.
В любом случае иметь разые бинарники с одной версией — это супр-грабли. Уж лучше решить проблему по автоматическому обновлению ссылок при открыии в студии или еще как-то, чем раскладывать такие грабли.
VD>>А вот идея делать разные сборки с один номером ревизии — это очень плохая идея. Потом будет невозможно понять откуда лезут баги.
Z>Юзкейс непонятного бага опиши.
Что там описывать то? Если версия (и строн-нэйм) одна и та же все будет пахать без перекомпиляции. Далее вариантом вагон и маленькая телезка. От банальных вылетов, до неразберихи.
Обеспечивать бинарную совместимость без средств контроля — это пипец!
Z>Тот subrev просто генерил нужный файл по шаблону. Мне такие решения не нравятся. Впрочем вот неплохое на первый взгляд решение.
Помоги, плиз, Кочеткову попробовать это дело в деле. У него нет каких-то лицензионных заморочек?
VD>>Нам надо научиться брать информацию из гитхаба. Например, список issue-ов. Вот лучше помоги разобраться как это делать.
Z>Это самое простое. У гитхаба есть REST API, все делается простыми запросами по урлу. http://develop.github.com/p/issues.html
Супер! Лучшая помощь от тебя была бы, если бы ты помог Кочеткову наладить автоматическую сборку билдов.
Ночной билд нам не нужен. Достаточно по запросу. Но важно достичь максимальной автоматизации. Так чтобы был один просто способ задать верхнюю верси (1.1.0._), префикс (Beta/RC и т.п.) и толкнуть серверный билд. А в результате или опубликованная версия, или отчет по мылу (или на экран).
IT мне тут как-то показывал свои наработки по деплою RSDN-а. Там прямо на веб-страницу выводился цветной output MSBuild-а собирающего проект на сервере. Вот нам бы что-то вроде этого. Можно и IT, если что дернуть.
Раньше мы пытались наладить ночные сборки, но свалились на проблеме сбоев при сборке. Если выдавать output MSBuild с сервера в броузер или на мыло, то это решило бы проблему. Главное чтобы обломы не проходили "молча" (чтобы то кто запустил билд и админы знали что что-то обломалось).
Уверен, что такое решение не только для немерлового проекта будет интересно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я сейчас занимаюсь инсталлятором для новой беты... Возникла пара вопросов, ответы на которые не вполне очевидны.
Раз уж дошли руки до инсталлятора, может все таки сделать ассоциацию .n файлов с иконкой, как должно быть, взять для этого ту большую иконку из NemerleStudio.
