Сами разработчики Rust гарантирую поддержку версий только в течение 6 недель, то есть до следующей версии. Однако тот же tokio написан под версию 1.70, которая уже больше года не поддерживается и имеет сильно урезанный функционал. Отсюда возникает заданный вопрос. С одной стороны, пользователи должны обновлять свои приложения каждые 6 недель под последнюю версию. Но, с другой стороны, я не верю, что они это делают, так как каждые 6 недель переписывать часть кодовой базы довольно дорого.
Где находиться идеальный компромисс (текущая версия, текущая версия - 1, текущая версия - 5 и так далее)?
А вариант выбирать текущую stable версию и своевременно обновлять, но фишки использовать условно 'прошлогодние' плюс как договоришься?
Если работаешь в команде, то выбор той или иной фишки нужно будет оговаривать предварительно.
Таким образом, и гнаться за самым соком не понадобится, и как минимум проект будет будет заранее проверяться на прочность новой версией.
Заморозка технологий имеет смысл только если связанные вещи это требуют, например используемые библиотеки, но в случае языка это менее выражено. Грубо говоря, если вы используете библиотеку, которая 'не собирается' в новой версии Rust, тогда вы либо ее переписываете либо остаетесь на последней поддерживаемой ею версии.
Кажется, наиболее логичная схема для нового проекта - это взять минимальную версию, с которой твой код компилируется, ибо врядли люди, которые сидят на сильно старой версии решат добавить себе новую зависимость ;)
Где находиться идеальный компромисс (текущая версия, текущая версия - 1, текущая версия - 5 и так далее)?
Кажется, тут стоит самому принять решения, ориентируясь на твоих потребителей и твои собственные ресурсы. Готов ли ты сам учитывать ограничения языка N-ной давности?
Простой
