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

·>Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется...

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

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

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

·>Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг, а PR висящий для ревью.

Можно настроить, чтобы варнинги считались ошибками и тогда такое не соберётся и придётся реагировать.
А обработка PR — это не вручную?
А править работу с библиотекой, если в новой версии интерфейсы поменялись и устарели используемые методы — это не вручную?
Чего мне в PR ревьюить, если изменение версии библиотеки — это просто в одном файле цифра поменялась и это справедливо и для MSBuild и для maven и для gradle?

·>Никак. Ты контекст потерял.

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

·>Нормально это как? Вручную?

Я уже писал: научить репозиторий запросам поиска, чтобы этим всем он занимался, а не каждый клиент выкачивал себе индексы и что-то там с ними делал.

·>Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки.

За исходники студии не плачу. Мне серьёзно вот нужно пояснять разницу между покупкой массового продукта и оплатой разработки под свои хотелки?

·>Непонятно, почему починкой этого не занялся подрядчик.

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

·>Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет.

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

·>Это больше юридическая проблема, чем техническая.

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

·>Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место.
·>Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы?

Какое знание где зафиксировано?
У меня в проекте зафиксирован репозиторий, который жив и работает.
Только по факту нужно прописать другой репозиторий, о котором мне никто ничего не сказал и я не знал о его существовании.
Они могли старый репозиторий отключить и я бы сидел с ошибкой, что нет доступа к репозиторию.
Теперь в десятке проектов нужно будет менять репозиторий, а если я захочу собрать старую версию ПО, то придётся опять мудрить, т.к. там не тот репозиторий прописан.

·>Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять.

Ну, вот Nuget плохой, т.к. с ним чаще работают через GUI.
Значит maven плохой, т.к. чаще репозитории прописывают в pom.xml, а не выносят во внешние файлы