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

Z>В том то и дело, что я пока еще ничего не предлагал. А ты уже сделал выводы:

VD>>Как я понял, ты предлагаешь зафиксировать версии сборок. Причем без малейшей аргументации и плюя на реальные аргументы.

О, как? А кто же предлагал зафиксировать версии немерловых сборок?

Z>Неверные выводы о моих предложениях на ровном месте.

А можно тогда описать свои предложения. Ну, так чтобы и до тупых вроде меня дошло?

VD>>А в чем тут проблема то? Мешает зависимость от Nemerle.dll?

Z>И от Nemerle.Compiler.dll.

Это как? От нее же только макросы должны зависеть.

Z>Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.

Я нечего не понимаю. Зачем влючать исходники утилиты?

Z>Да и вообще, как я включу исходники Nemerle.dll в nrails?

Создаешь каталог, копируешь туда исходники и включаешь каталог в проект.

Z>Как их мейнтейнить?

Прости, что?

Z>Как потом использовать nrails из немерловых проектов? Там же будут конфликты со стандартной либой. Абсолютно неработоспособное решение.

Дык твоя библиотека и будет экспотировать все нужные функции.

Как вариант, можно простеньким макросом махнуть все public-и на internal и тогда все импортируемые типы будут локальны для проекта.

Z>Ну так она не будет меняться на каждый комит и мне не придется ребилдить зависимости чаще чем это реально требуется. Лучшим выходом было бы фиксировать версию и публичный API на каждый минорный релиз. Обновлять все раз в полгода я не против. Если это сейчас невозможно, надо думать о том, как сделать так, чтобы стало возможно.

Nemerle.Compiler.dll, о зависимости от которой ты писал выше, меняется чуть ли ни каждый день. Не всегда меняется публичный интерфейс, но как это определить?

И вообще, как ты себе видишь реализацию этой идеи? Как определить, что в сборке что-то изменилось и ей нужно менять ее версию?

Ты вручную предлагаешь это делать?

Z>Пойми, пока не решена эта проблема, нет смысла патчить nuget для поддержки немерла. Ибо создавать либы на nemerle сейчас нет никакого смысла. Они могут быть использованы только с конкретной версией компилятора.

Ну, придумай как программно определить, что изменился публичный интерфейс. Тогда можно будет менять версии только при его изменении.

Но, по-моему, проще включать исходники Nemerle.dll в состав таких библиотек.
Написать макрос который будет менять все public-и на internal-ы для конкретного каталога — это задача на пол часа.

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

VD>А можно тогда описать свои предложения. Ну, так чтобы и до тупых вроде меня дошло?

Для начала предлагаю признать, что проблема существует. А не отмахиваться кучей костылей, которые ее якобы решают.

VD>>>А в чем тут проблема то? Мешает зависимость от Nemerle.dll?

Z>>И от Nemerle.Compiler.dll.

VD>Это как? От нее же только макросы должны зависеть.

nrails умеет компилировать миграции и компилировать спарковские вьюхи. Макросы там, опять же, присутствуют.

Z>>Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.

VD>Я нечего не понимаю. Зачем влючать исходники утилиты?

Какой утилиты? Миграции это сборка, исходники для которой активно правятся. Сборку надо собирать и запускать как вручную, так и из основного проекта, в процессе апгрейда версии. Эта сборка ссылается на nrails.dll, и использует nrails.macros.dll при компиляции. Те, в свою очередь ссылаются на Nemerle.dll и Nemerle.Macros.dll.

VD>Создаешь каталог, копируешь туда исходники и включаешь каталог в проект.

Z>>Как их мейнтейнить?

VD>Прости, что?

Поддерживать. Вот исправили какой-то баг в стандартной либе, я что должен делать? Но это даже не главное, о главном ниже.

VD>Дык твоя библиотека и будет экспотировать все нужные функции.

Так они будут несовместимы с Nemerle.dll. Вот отсюда я уже не получу свой list.

VD>Как вариант, можно простеньким макросом махнуть все public-и на internal и тогда все импортируемые типы будут локальны для проекта.

Но их невозможно будет использовать совместно с типами из Nemerle.dll. Мне нужна возможность писать на nemerle библиотеки/макросы, которые (в скомпилированном виде) можно использовать в других проектах более чем в одной версии компилятора.

VD>Nemerle.Compiler.dll, о зависимости от которой ты писал выше, меняется чуть ли ни каждый день. Не всегда меняется публичный интерфейс, но как это определить?
VD>И вообще, как ты себе видишь реализацию этой идеи? Как определить, что в сборке что-то изменилось и ей нужно менять ее версию?

Слава богу, пошел конструктивный разговор. Как вариант — тест на эталонную сборку. Как только выходит минорная бэта, создается ветка для ее багфиксов, в нее кладутся выложенные сборки и включатеся тест, который сличает публичные интерфейсы. В билдскрипты ревизия прописыватеся жестко. В этой ветке правятся баги, она же регулярно мерджится в мастер. Релизы выкатываются из нее. В мастер же комитятся и мерджатся новые фичи. Это сырой вариант схемы, если в нем что-то не нравится, давай обсуждать.

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

Z>Для начала предлагаю признать, что проблема существует. А не отмахиваться кучей костылей, которые ее якобы решают.

Да, я что против что ли? Такая проблема будет существовать с любой библиотечной сборкой дотнета используемой в нескольких проектах одновременно.
Звучит она просто — к одному приложению нельзя подключить две разные версии одной сборки (даже опосредованно).

Z>nrails умеет компилировать миграции и компилировать спарковские вьюхи. Макросы там, опять же, присутствуют.

Макросы не входят во внешние зависимости. По крайней мере не должны. Они же только для компиляции нужны.

Если у тебя есть импорт типов из макро-сборок, то это уже твоя вина. Подключи их как макро-референсы и избавься от зависимости по типам.

Z>>>Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.

VD>>Я нечего не понимаю. Зачем влючать исходники утилиты?

Z>Какой утилиты? Миграции это сборка, исходники для которой активно правятся. Сборку надо собирать и запускать как вручную, так и из основного проекта, в процессе апгрейда версии. Эта сборка ссылается на nrails.dll, и использует nrails.macros.dll при компиляции. Те, в свою очередь ссылаются на Nemerle.dll и Nemerle.Macros.dll.

Ну, так получается, что все же от нее ничего не зависит. Так?
Тогда для нее можно иметь свои зависимости (сборки компилятора).

VD>>Создаешь каталог, копируешь туда исходники и включаешь каталог в проект.
Z>>>Как их мейнтейнить?
VD>>Прости, что?

Z>Поддерживать. Вот исправили какой-то баг в стандартной либе, я что должен делать? Но это даже не главное, о главном ниже.

Скопировать исходники из одного каталога в другой и пересобрать проект.

VD>>Дык твоя библиотека и будет экспотировать все нужные функции.

Z>Так они будут несовместимы с Nemerle.dll. Вот отсюда я уже не получу свой list.

Это — да. Придется и эти исходники включать к себе в проект.

Z>Слава богу, пошел конструктивный разговор. Как вариант — тест на эталонную сборку. Как только выходит минорная бэта, создается ветка для ее багфиксов, в нее кладутся выложенные сборки и включатеся тест, который сличает публичные интерфейсы. В билдскрипты ревизия прописыватеся жестко. В этой ветке правятся баги, она же регулярно мерджится в мастер. Релизы выкатываются из нее. В мастер же комитятся и мерджатся новые фичи. Это сырой вариант схемы, если в нем что-то не нравится, давай обсуждать.

Не, не не. Минорная, мажорная, ветка, закладывается и другая рукопашная фигня меня не устраивает. Я тебе уже много раз говорил — нужен автомат.

И я не вижу как это сделать. Закладываться на какое-то там рукопашное закладывание сборок и, тем более, ручную замену версий нельзя. Это неминуемо приведет к проблемам.

Чтобы твоя схема взлетела нам нужно иметь целый отряд который только реализами и будет заниматься. Мы не МС, так что отряда явно не будет. Так что нужно искать выход по проще.

Как вариант, можно рассмотреть следующее...

Компилируем Nemerle.dll в два прохода. После первого сравниваем (через рефлексию) публичный интерфейс новой сборки с той что лежит в boot-е. Если публичный интерфейс сходится, то просто копируем получившуюся сборку (со старой версией) в оутпут второго прохода. Если же публичный интерфейс изменился, производим повторную компиляцию этой сборки. При этом она получает новую версию (полученную путем икремента на единицу версии сборки из boot-а). Далее копируем полученную сборку в бут.

За одно это автоматизирует обновление бута.

В принципе тоже самое можно делать из с Nemerle.Compiler.dll. Но вот с библиотеками вроде Nemerle.Linq.dll Nemerle.Peg.dll ComputationExpressions.dll — это не прокатит, так как они не хранятся в буте.

Опять же кому-то нужно заняться реализацией — этого (не самого простого) алгоритма. Возьмешься?

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

VD>Макросы не входят во внешние зависимости. По крайней мере не должны. Они же только для компиляции нужны.

VD>Если у тебя есть импорт типов из макро-сборок, то это уже твоя вина. Подключи их как макро-референсы и избавься от зависимости по типам.

Все кругом у тебя виноваты, лишь бы не лезли с проблемами. Макросборка использует типы из Nemerle.dll из той Nemerle.dll с которой она была собрана. А выполняется она компилятором, у которого своя Nemerle.dll.

VD>Это — да. Придется и эти исходники включать к себе в проект.

Я вижу ты уже понял основную проблему. Разработчик библиотеки просто в тупике. Либо включать весь немерл себе в проект в исходниках, и обязывать пользователей своей библотеки отключать стандартную библиотеку в их собственных приложениях. Либо распостранять свою либу в исходниках и требовать пользователей пересобирать ее при каждом апгрейде компилятора.

VD>Не, не не. Минорная, мажорная, ветка, закладывается и другая рукопашная фигня меня не устраивает. Я тебе уже много раз говорил — нужен автомат.

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

Z>Все кругом у тебя виноваты, лишь бы не лезли с проблемами.

Справедливости ради, это проблема не только немерла, но и всех компиляторов под .нет. Но тут она усугубляется тем, что немерле чуть ли не раз в неделю обновляется (в отличии от, допустим, C#, который обновляется раз в два года), и макросами.

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

C>Справедливости ради, это проблема не только немерла, но и всех компиляторов под .нет. Но тут она усугубляется тем, что немерле чуть ли не раз в неделю обновляется (в отличии от, допустим, C#, который обновляется раз в два года), и макросами.

Угу. Обновляется, а стабильной ветки, в которой только багфиксы, не имеет. Сервиспаки на фреймворк выходили между версиями. Но они не меняли версии сборок.

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

C>>Справедливости ради, это проблема не только немерла, но и всех компиляторов под .нет. Но тут она усугубляется тем, что немерле чуть ли не раз в неделю обновляется (в отличии от, допустим, C#, который обновляется раз в два года), и макросами.

Z>Угу. Обновляется, а стабильной ветки, в которой только багфиксы, не имеет. Сервиспаки на фреймворк выходили между версиями. Но они не меняли версии сборок.

При любом сервис-паке приходится перекомпилировать проект. А при смене версий народ по году перейти между ними не может. Так что с немерлом все даже намного проще.

А то что что-то там обновляется раз в неделю, так ты не обязан эти изменения качать. Релизы у немерла тоже не часто бывают. Если среди изменений нет жизненно необходимых для тебя, так просто используй старую версию.

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

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

VD>>Макросы не входят во внешние зависимости. По крайней мере не должны. Они же только для компиляции нужны.

VD>>Если у тебя есть импорт типов из макро-сборок, то это уже твоя вина. Подключи их как макро-референсы и избавься от зависимости по типам.

Z>Все кругом у тебя виноваты, лишь бы не лезли с проблемами.

А ты хочешь чтобы я был виноват во всех внешних проблемах? Может ты меня и во внешней политике США обвинишь?

Z>Макросборка использует типы из Nemerle.dll из той Nemerle.dll с которой она была собрана.

Макра-сборка по любому должна быть той версии что и компилятор. Но твои конечные длл-и от этого никак не зависят.

Z>А выполняется она компилятором, у которого своя Nemerle.dll.

Ну, дык, а что ты хочешь то? Макросбрка плотно связана с компилятором. Она не может жить с другой версией стандартных библиотек.

VD>>Это — да. Придется и эти исходники включать к себе в проект.

Z>Я вижу ты уже понял основную проблему. Разработчик библиотеки просто в тупике. Либо включать весь немерл себе в проект в исходниках, и обязывать пользователей своей библотеки отключать стандартную библиотеку в их собственных приложениях. Либо распостранять свою либу в исходниках и требовать пользователей пересобирать ее при каждом апгрейде компилятора.

Мне кажется второй способ, в условиях постоянного обновления компилятора — это самый удобный и правильный выход из ситуации.
Второй разумный выход — не брать новую версию компилятора по утрам. Устраивает тебя текущая версия? Ну, так и используй ее. Будет официальный релиз (ну, хотя бы бэта официальная) — то и обновишь компилятор и перекомпилируешь все библиотеки.

VD>>Не, не не. Минорная, мажорная, ветка, закладывается и другая рукопашная фигня меня не устраивает. Я тебе уже много раз говорил — нужен автомат.

Z>

Я лучше слова понимаю. Что значит этот смайлик я не понимаю.

Я тебя прямо и ответственно заявляю, что никакой ручной работой по сборке и публикации я заниматься не буду. У меня и так времени ни на что не хватает, а здоровье уже дышит наладом, из-за того, что вместо сна я немерлом занимаюсь.

Кочеткову тоже времени не хватает. Он даже запланированные изменения не успевает сделать.

Так просто пойми — никто не против идеи менять версии сборок только при изменении публичного интерфейса. Но требуется чтобы это происходило автоматом. Раз эта задача тебе нужна больше чем остальным, то берись за нее. Продумай как все сделать просто и качественно и реализуй. Если найдутся помощники, то вообще прекрасно. Уверен, что с технической точки зрения задача решается. Вопрос только в усилиях по ее продумыванию и реализации.

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

Z>>Угу. Обновляется, а стабильной ветки, в которой только багфиксы, не имеет. Сервиспаки на фреймворк выходили между версиями. Но они не меняли версии сборок.

VD>При любом сервис-паке приходится перекомпилировать проект. А при смене версий народ по году перейти между ними не может. Так что с немерлом все даже намного проще.

Не надо ничего перекомпилировать. Все отлично работает и без этого.

VD>А то что что-то там обновляется раз в неделю, так ты не обязан эти изменения качать. Релизы у немерла тоже не часто бывают. Если среди изменений нет жизненно необходимых для тебя, так просто используй старую версию.

Точка зрения понята.

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

Z>>Все кругом у тебя виноваты, лишь бы не лезли с проблемами.

VD>А ты хочешь чтобы я был виноват во всех внешних проблемах? Может ты меня и во внешней политике США обвинишь?

У тебя очень полярный взгляд на вещи.

VD>Макра-сборка по любому должна быть той версии что и компилятор. Но твои конечные длл-и от этого никак не зависят.

Тогда я не пойму, зачем ты их выделяешь из общего списка.

VD>Мне кажется второй способ, в условиях постоянного обновления компилятора — это самый удобный и правильный выход из ситуации.

VD>Второй разумный выход — не брать новую версию компилятора по утрам. Устраивает тебя текущая версия? Ну, так и используй ее. Будет официальный релиз (ну, хотя бы бэта официальная) — то и обновишь компилятор и перекомпилируешь все библиотеки.

Мысль ясна. В таком случае нет никакого смысла писать опенсорсные либы типа nrails. Подключать их в каждый проект в исходниках удовольствие ниже плинтуса.

Z>>

VD>Я лучше слова понимаю. Что значит этот смайлик я не понимаю.

Развожу руками, что мне остается?

VD>Так просто пойми — никто не против идеи менять версии сборок только при изменении публичного интерфейса. Но требуется чтобы это происходило автоматом. Раз эта задача тебе нужна больше чем остальным, то берись за нее. Продумай как все сделать просто и качественно и реализуй. Если найдутся помощники, то вообще прекрасно. Уверен, что с технической точки зрения задача решается. Вопрос только в усилиях по ее продумыванию и реализации.

Влад, это управление релизами. Его еще никто не смог автоматизировать. Нужно багфиксы делать в одной ветке, а фичи в другой. Никакая автоматизация этого не решит, все что она может, это сказать, что публичный интерфейс изменен. Я понимаю, что хочется просто писать код и ни о чем больше не думать.

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

VD>>А ты хочешь чтобы я был виноват во всех внешних проблемах? Может ты меня и во внешней политике США обвинишь?

Z>У тебя очень полярный взгляд на вещи.

Что значит "полярный"?

VD>>Макра-сборка по любому должна быть той версии что и компилятор. Но твои конечные длл-и от этого никак не зависят.

Z>Тогда я не пойму, зачем ты их выделяешь из общего списка.

Из какого списка? Просто твои ДЛЛ-и не должны зависеть от версии Nemerle.Compiler.dll. От нее должны зависеть только макро-сборки.

VD>>Мне кажется второй способ, в условиях постоянного обновления компилятора — это самый удобный и правильный выход из ситуации.

VD>>Второй разумный выход — не брать новую версию компилятора по утрам. Устраивает тебя текущая версия? Ну, так и используй ее. Будет официальный релиз (ну, хотя бы бэта официальная) — то и обновишь компилятор и перекомпилируешь все библиотеки.

Z>Мысль ясна. В таком случае нет никакого смысла писать опенсорсные либы типа nrails. Подключать их в каждый проект в исходниках удовольствие ниже плинтуса.

Отличный вывод! Логика железная!

Z>Развожу руками, что мне остается?

Ну, можно взять и сделать как удобнее тебе и хорошо другим.

Идея тупо не менять версии — плохая. Надеюсь ты это понимаешь. Идея менять версии при изменении публичного интерфейса — хорошая, но требующая реализации.

Так почему бы вместо того чтобы обвинять меня в том, что я никогда не делал, не взяться за реализацию правильного решения?

VD>>Так просто пойми — никто не против идеи менять версии сборок только при изменении публичного интерфейса. Но требуется чтобы это происходило автоматом. Раз эта задача тебе нужна больше чем остальным, то берись за нее. Продумай как все сделать просто и качественно и реализуй. Если найдутся помощники, то вообще прекрасно. Уверен, что с технической точки зрения задача решается. Вопрос только в усилиях по ее продумыванию и реализации.

Z>Влад, это управление релизами. Его еще никто не смог автоматизировать.

Ерунду то не говори.

Z>Нужно багфиксы делать в одной ветке, а фичи в другой. Никакая автоматизация этого не решит, все что она может, это сказать, что публичный интерфейс изменен. Я понимаю, что хочется просто писать код и ни о чем больше не думать.

Ну, берись вручную управлять релизами. Будешь сам делать инсталляторы, следить за версиями и т.п. До тех пор пока ты этим будешь заниматься будем выпускать все вручную. Боюсь, что ты этим прозанимаешься примерно неделю. А дальше бросишь.

На себя я такие обязанности взваливать не собираюсь. Это займет 100% моего, и так недостаточного, времени.

Пойми — в наших условиях, некоммерческой разработки малыми силами, мы и так делаем больше чем можем. Чтобы при таких ресурсах обеспечивать надлежащее качество в приемлемые сроки мы обязаны автоматизировать все что возможно.

Выпуск реализов — это то что можно и нужно автоматизировать. Если мы будем делать их все время вручную, то в них банально не будет чего включать.

По сему чем критиковать, сам не знаешь чего, лучше помоги сделать добротную автоматизацию.

ЗЫ

Что касается Майкрософта... У них реализы равз в год, а то и реже. Любая новая версия вызывает не просто перекомпиляцию, а серьезнейшие проблемы у кучи народа. Многие годами не могут перейти на новый фрймворк, даже когда сам рантайм не изменялся (2.0, 3.0, 3.5 имеют один рантайм).

Мы можем пойти по тому же пути и тогда можно будет обеспечивать ручное управление выпусками. Но будет ли это преимуществом? Уверен, что нет. И большая часть людей предпочтет перекомпилировать свои библиотеки, но не ждать исправлений годами.

Так же уверен, что в МС есть система контроля изменения публичного интерфейса, которая и позволяет вести несущественные изменения. Плюс, скорее всего, при релизе там тупо дублируют репозиторий и ведут их отдельно, так как много раз видел как в новых версиях продуктов МС были те же ошибки, что были испрвлены в фиксах или сервиспаках к предыдущим версиям. Мы так делать не можем. Далеть же мерджи из одной ветки в другую можно до первого серьезного рефакторинга. Далее или нужно синхронизировать обе ветки (что убьет совместимость интерфейса), или полностью разделять репозитории.