Redash v25.8.0: что нового
Обзор релиза Redash v25.8.0 — что важного, что сломали, стоит ли обновляться
Вышел Redash 25.8.0. Релиз, который не кричит о революции, но исправно закручивает гайки и подчищает исторические долги. Если у вас стоит Redash в продё — вот что нужно знать.
Что важного
Главное — официальная поддержка PostgreSQL 16. База — это позвоночник Redash, и если вы уже бежите впереди планеты всей с шестнадцатой версией, теперь можете обновиться без танцев с бубном. Внутри тихо обновили несколько ключевых зависимостей, включая cryptography и psycopg2, что закрывает уязвимости и поддерживает совместимость.
Добавили новый алгоритм хеширования паролей — scrypt. Старый добрый bcrypt никуда не делся, но scrypt считается более устойчивым к атакам на специализированном железе. Для новых инсталляций это будет по умолчанию. Для существующих — всё продолжит работать, но можно будет переехать в фоне.
Небольшая, но приятная опция для тех, кто крутит Redash в Kubernetes через официальный Helm-чарт: теперь можно задать securityContext для контейнера инициализации БД. Мелочь, а иногда именно её не хватает для прохождения compliance в строгом кластере.
Что сломали
Тихий, но решительный шаг по зачистке legacy. Окончательно удалена давно объявленная устаревшей функция redash.models.Changes. Если вы каким-то чудом всё ещё используете её в своих кастомных скриптах или плагинах — они перестанут работать.
Убрали неиспользуемый аргумент multi_byte из функции to_epoch. Вряд ли это кого-то зацепит, но если вы вызывали эту функцию напрямую из своего кода — проверьте сигнатуру.
Ещё одно изменение в поведении: теперь при создании пользователя через API или CLI обязательно нужно указывать организацию (org_id). Раньше можно было не указывать, и пользователь попадал в организацию по умолчанию. Теперь — нельзя. Автоматические скрипты создания пользователей могут сломаться.
Обновляться или подождать
Если вы не сидите на PostgreSQL 16 и у вас нет кастомных скриптов, завязанных на удалённые функции — обновляйтесь спокойно. Миграция через docker-compose run --rm server manage db upgrade стандартная. Если же вы — любитель глубокой кастомизации, пробегитесь по списку breaking changes. В целом, деплой не рассыпется.