В процессе развития экосистемы окружение меняется. Меняется фреймворк, меняется Shop-Script. Часть пользователей не продлевает подписку или остаётся на старых версиях фреймворка.
в плагинах приходится либо тащить за собой кучу костылей, для того чтобы продолжать поддерживать совместимость, либо просто кидать пользователей "обновляйся или умри", а это неблагоприятно сказывается на общем восприятии платформы в целом.
Например интерфейсы печатных форм в Shop-Script менялись уже дважды. Часть методов давно помечена, как deprecated. Чтобы пользователи с ископаемыми версиями SS типа 6.3 или 7.5 продолжали получать обновления приходится отказываться от возможностей, заложенных в SS8 или проверять в плагине версию текущего окружения.
Кроме того, не так уж редка ситуация, когда устаревший софт переносится на другой хостинг, часть каких-то файлов теряется, а у владельца лицензии нет возможности установить продукт .за который он заплатил, из Инсталлера. Сейчас приходится присылать этим несчастным архив для ручной установки :(
8 комментариев
Считаю, что в инсталлере должна быть возможность установки всех версий продуктов, которые когда-либо выпускались разработчиком (или хотя бы всех версий продуктов, которые выпускались разработчиком начиная с определенной даты, если старые версии продуктов нигде не хранятся). Это было бы удобно не только в описанной в теме ситуации, но и в гораздо более часто встречаемой ситуации: обнаружение багов в новой версии продукта.
Что происходит сейчас:
- пользователь обновился
- словил баг
- либо восстанавливает сайт из бекапа, либо бегает/психует/донимает поддержку WA/донимает поддержку плагина, судорожно просит дать ему старую версию плагина и не получив ее за 10 минут в дальнейшем оказывает "негативное воздействие на восприятие платформы".
Такой сценарий был бы более правильным:
- обновился
- словил баг
- установил старую версию продукта через инсталлер
- во время установки старой версии продукта заполнил форму "Причина установки старой версии продукта", которая отправляется разработчику (опционально).
У вас есть примеры подобной реализации где либо?
С простыми плагинами это возможно. А что делать с метаобновлениями базы? Дропать таблицы и создавать заново для нужной версии? Не вариант. Там возможно десятки человеко-часов на ввод данных затрачено, да и сами данные обычно весьма ценны.
Объясните пожалуйста простыми словами: в каких случаях плагин X (который что-то хранит в БД) версии 1.0, будучи обновленным до версии 2.0, больше нельзя откатывать обратно до версии 1.0 не трогая БД (и почему)?
1. Метаобновление могут удалять файлы. Совсем.
2. Метаобновления могут менять структуру таблиц - удалить поле, разбить его на отдельные записи, перенести данные в другие таблицы.
ок, более менее понял. спасибо что объяснили.
Вопрос на засыпку. Движок же видит что в обновлении продукта есть метаобновления?
Теоретически можно было бы сделать чтобы инсталлер получал информацию о том что:
— в обновлении продукта X в версии 2.0 есть метаобновление
— в обновлении продукта Y в версии 2.0 нет метаобновлений
И получив эту информацию:
1) Показать что обновление продукта X 2.0 содержит метаобновление, после установки будет невозможен откат и в случае обнаружения проблем рекомендуется сделать полный откат сайта
2.1) Показать что обновление продукта Y 2.0 не содержит метаобновлений и после установки продукта его можно будет откатывать без отката базы данных
2.2) Вывести волшебную кнопку переустановки продукта Y на старую версию 1.0. (при нажатии на которую перед "переустановкой" нужно обязательно указать причину установки старой версии продукта, которая передастся разработчику)
Есть ощущение, что такое нововведение хоть и не принесет денег в казну, но может сильно помочь как пользователям, так и разработчикам.
Алексей ответил уже.
Да, примерно всё так. Новая версия может неузнаваемо изменить структуру и перемешать старые данные. Чтобы поменять всё обратно, старая версия плагина должна знать об этом. Но естественно, что она об этом не знает.
Как вариант, можно в новой версии, помимо install.php/uninstall.php, добавить еще и что-то вроде revert.php...но это пипец. Сейчас никого не заставишь делать новые(старые) версии, в которые необходимо добавлять этот revert(и кто их все будет модерировать?), чтобы по обратной цепочке версий восстанавливать базу. Как-то бредово это всё -)
Для новых версий - возможно и реализуемо, но опять же надо отсекать старые версии плагинов, которые это не поддерживают.
Обычное дело. Для миграций в разных ORM, например Propel, создаются сразу как update, так и downgrade инструкции. Ну, возможно, при downgrade часть данных будет потеряна.
Другая проблема, конечно, в удалённых файлах. Но они же есть в предыдущей версии. Можно и восстановить, а новый, наоборот, удалять.
Задача довольно трудная.
На самом деле изначально я своей темой не планировал возможности отката, лишь возможность раздавать какие-то определённые версии для разных типов оружений.
Вот, условно, у меня сейчас есть плагин версии 2.11.2 который требует PHP 5.6 и не очень новой версии фреймворка. Недавно я выпустил версию 3.0, теперь требуется PHP 7.2 минимум и фреймворк 1.13. Для меня не проблема поддерживать ветку 2.x в плане исправления каких-то недочётов, но развития там не будет. Тем не менее хорошо бы раздавать старую версию (и обновления к ней) для тех, кто не может использовать новую.