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

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

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

C>Возможно имеет смысл менять версии библиотек компилятора (Nemerle.dll, Nemerle.Compiler.dll) только когда изменяется их публичный API.

C>Тогда необязательно будет пересобирать все проекты под каждую новую версию компилятора.

Дело в том, что они берут версию из SVN — это номер их ревизии.

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

H>Дело в том, что они берут версию из SVN — это номер их ревизии.

Не в каждой же ревизии изменяется API. Если бы это исправить, можно было бы всегда работать на самой свежей версии компилятора, не пересобирая по сто раз свои библиотеки.

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

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

H>>Дело в том, что они берут версию из SVN — это номер их ревизии.

C>Не в каждой же ревизии изменяется API. Если бы это исправить, можно было бы всегда работать на самой свежей версии компилятора, не пересобирая по сто раз свои библиотеки.

Хм. А если не привязывать библиотеки к строгим именам?

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

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

C>>Возможно имеет смысл менять версии библиотек компилятора (Nemerle.dll, Nemerle.Compiler.dll) только когда изменяется их публичный API.

C>>Тогда необязательно будет пересобирать все проекты под каждую новую версию компилятора.

H>Дело в том, что они берут версию из SVN — это номер их ревизии.

Номер ревизии из SVN можно помещать в AssemblyFileVersion, а версию AssemblyVersion, которая проверяется при разрешении зависимостей, можно менять как предлагает catbert — при изменении публичного API.

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

I>Номер ревизии из SVN можно помещать в AssemblyFileVersion, а версию AssemblyVersion, которая проверяется при разрешении зависимостей, можно менять как предлагает catbert — при изменении публичного API.

Вообще интересная мысль

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

I>Номер ревизии из SVN можно помещать в AssemblyFileVersion, а версию AssemblyVersion, которая проверяется при разрешении зависимостей, можно менять как предлагает catbert — при изменении публичного API.

И что? Полагаться на людей? Изменили версию — хорошо. Забыли, ну что же... тут ничег не поделаешь...

Так что ли?

Мне кажется один ребилд после переустановки компилятора — это не так страшно.

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

VD>И что? Полагаться на людей? Изменили версию — хорошо. Забыли, ну что же... тут ничег не поделаешь...

VD>Так что ли?

Ну, вообще-то изменения в публичном API должны покрыватся тестами в любом случае. Кроме того, можно написать тулзу, которая будет отслеживать такие изменения.

VD>Мне кажется один ребилд после переустановки компилятора — это не так страшно.

Не так страшно — это если редко переустанавливать компилятор. А я (и, судя по всему, не только я) стараюсь так делать как можно чаще, чтобы тестировать самую новую версию.

Кстати, можно кроме инсталлятора выкладывать для скачивания просто бинарники компилятора/библиотек, чтобы можно было без установки тестировать разные версии компилятора. И чтобы было что скачивать тем, кто использует mono.

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

C>Возможно имеет смысл менять версии библиотек компилятора (Nemerle.dll, Nemerle.Compiler.dll) только когда изменяется их публичный API.

Наверное, так не выйдет. Ведь подписывается все равно вся библиотека, не только её общие части. В результате, версию придётся менять при любом изменении библиотеки (что всё равно существенно реже чем при каждой ревизии).

Иногда не хватает файлов заголовков, как в C++

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

C>Ну, вообще-то изменения в публичном API должны покрыватся тестами в любом случае.

Да какая разница что отслеживать вручную?

C>Кроме того, можно написать тулзу, которая будет отслеживать такие изменения.

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

Кстати, кроме стандартной библиотеки еще придется отслеживать стандартную библиотеку макросов. А в ней есть ряд макросов относящихся к компилятору.

C>Не так страшно — это если редко переустанавливать компилятор. А я (и, судя по всему, не только я) стараюсь так делать как можно чаще, чтобы тестировать самую новую версию.

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

C>Кстати, можно кроме инсталлятора выкладывать для скачивания просто бинарники компилятора/библиотек, чтобы можно было без установки тестировать разные версии компилятора. И чтобы было что скачивать тем, кто использует mono.

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

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

ЗЫ

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