Обращение к разработчика (независимым)

BNP (Дмитрий)

Коллеги, здравствуйте.

Извините, но поднакопилось.

Убедительная просьба, пишите пожалуйста для своих плагинов хоть где-нибудь (но лучше на видном месте), что они работают ТОЛЬКО для shop-script 7. И если в обновлениях вы начинаете пользовать что-то из семерки, просьба тоже писать в changelog, что дальше работаем только на семерке.

Последний пример. Плагин SEO-регионы. Клиент на шестерке обновил плагин до последней (2.0) версии. И все. Редактирование поддоменов отвалилось. Почему? Потому что в классе shopRegionsHelper используется вот это

shopHelper::getStocks()

Но в шестой версии(6.3.0.44568) в классе shopHelper нет метода getStocks(). Пришлось его туда вкорячить, попутно закоментив работу с виртуальными складами. Только вот еще возникает вопрос ... где еще что может всплыть =(

И это, к сожалению, не единичный случай. Просто он последний.

9 декабря 2016
  • waResearchLab 9 декабря 2016 00:58

    Вполне разумно. Вот только я б добавил, что совместимость с 5-6-7, раз уж все они кормятся из одного магазина, должна проверяться на стадии модерирования, и в случае отсутствия соответствующей информации в requirements.php делать ай-я-й-яй разработчику. Ну и на стадии тестирования разработчиком тоже конечно проверяться должно.

  • Olga Mamizheva 9 декабря 2016 10:48

    +1

    Причем, нужна расширенная система проверки версий, чтобы у пользователей Shop-script 5/6 не висел постоянно горящий бейджик о доступности обновлений, которые они не могут установить на старую систему.

  • Владислав Горлов Webasyst 9 декабря 2016 16:36

    Модераторы не в силах проверять каждое использование методов. Моя личная позиция заключается в том, что обеспечить совместимость как с разными версиями PHP, так и с разными версиями продуктов - не так уж и сложно (но ряд сторонних разработчиков не разделяет такой позиции :) ).

    Со своей стороны постараемся добавлять в PHP Doc комментариях к новым методам версии продукта, в которых они появились для простоты формирования системных требований.

  • info@ravencode.ru 12 декабря 2016 17:33

    requirements.php по моему отлично решает данную проблему, если б в плагинах магазина в обязательном порядке прописывалась мин. версия shop, то клиент бы не смог обновить плагин + все косяки совместимости ложились бы автоматом на разработчика.

  • BNP (Дмитрий) 12 декабря 2016 17:48

    Не изучал алгоритм, а requirements.php при обновлениях какую-то роль играет?

    Т.е. если первоначально были одни требования, а потом requirements.php поменяли, обновление не встанет?

  • Владислав Горлов Webasyst 12 декабря 2016 17:53

    Если список строгих требований, декларированных в requirements.php обновленного плагина/приложения не удовлетворяется, то обновление нельзя установить.

  • info@ravencode.ru 12 декабря 2016 22:02

    Владислав, обновленного или обновляемого? запутали, идеальный вариант: если бы данный файл проверялся и при обновлениях (если сейчас не реализовано).

  • Владислав Горлов Webasyst 13 декабря 2016 12:00

    Сервер обновлений отдает системные требования для новой версии — они и проверяются.

  • info@ravencode.ru 13 декабря 2016 12:50

    Ну вот осталось только закрепить в регламенте разработчика инфу о том что он должен указать минимально совместимую версию своего продукта. WA добавьте в todo, идея Дмитрия действительно полезная.



Чтобы добавить комментарий, зарегистрируйтесь или войдите