Маркет: Как будут разрешаться ситуации при отказе в работе продукта после обновления билда ?
...
ЗЫ. Пока что радует то, что компания развивается, и сама организует и поддерживает Маркет и продажу продуктов MQL5. Следовательно, борьба за качество будет, но кто будет платить за это своей репутацией и рублем?
Вопросы очень актуальные. И нужно найти решение. У меня уже есть предложение.
Например, можно сделать так. Чтобы установить очередное обновление (билд) для торгового терминала пользователь сам решает, устанавливать его или нет. То есть, нужно сделать так, чтобы он знал о новом билде, но смог сам решить, когда это можно сделать. Разработчики приложений тогда должны иметь две версии установленного терминала. Одна версия с предыдущим билдом, а вторая версия с последним билдом. Если багов в новом билде при использовании продукта не обнаружено, то продавец делает пометку в Маркете, что продукт совместим с последним билдом. Если продукт на последнем билде начинает "глючить", то пометку не ставим и пользователь будет знать, что устанавливать новый билд пока рано.
Это как вариант. Нужно ещё думать...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
Собственно вопрос этот назревал давно.
Что теперь делать трём сторонам?
Двум. Программист ваще не при чем. А Покупатель просто должен иметь возможность скачать новый маркетный ex . Без писем , просьб , капчей, уведомлений подтверждений и т.д.
Разумеется только на то железо , где уже стоит.
У продуктов есть штатная версионность, об этом можно прочитать в статье https://www.mql5.com/ru/articles/385
При выходе новой версии будет автоматическое предложение обновить программу. Такой вариант хорошо подходит для обновления минорных версий типа 2.хх
При выпуске мажорных версий нужно будет регистрировать новый продукт, чтобы иметь возможность повторной продажи или продолжать выпускать новые версии под старой регистрацией с автоматическим бесплатным апгрейдом для существующих клиентов.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
У продуктов есть штатная версионность, об этом можно прочитать в статье https://www.mql5.com/ru/articles/385
При выходе новой версии будет автоматическое предложение обновить программу. Такой вариант хорошо подходит для обновления минорных версий типа 2.хх
При выпуске мажорных версий нужно будет регистрировать новый продукт, чтобы иметь возможность повторной продажи или продолжать выпускать новые версии под старой регистрацией с автоматическим бесплатным апгрейдом для существующих клиентов.
Да, это то что касается новых версий продуктов.
Но это немного не то, про что вопрос в теме.
А интересует как быть, если новый билд терминала блокирует нормальную работу софта?
Если прикинуть, то билды выходят примерно два раза в месяц. Получается, что обновив терминал, покупатель на пару недель потеряет возможность пользоваться продуктом. Вот про это речь.
Не только. Программист должен бросить свою текущую работу и заняться отловом бага. А если у него несколько продуктов в маркете?
таки получают геморрой все.
но какое решение может быть?
но какое решение может быть?
решения нет.
пока не появится новый билд с исправлениями так и будет продукт простаивать (или приносить убыток покупателю, а может и прибыль - кто знает? - тогда после исправления бага терминала толпа пользователей возмущённо будут требовать вернуть баг в терминал обратно?).
Если багов в новом билде при использовании продукта не обнаружено, то продавец делает пометку в Маркете, что продукт совместим с последним билдом. Если продукт на последнем билде начинает "глючить", то пометку не ставим и пользователь будет знать, что устанавливать новый билд пока рано.
Т.е. на продавце ещё лежит и ответственность за отлов багов новых билдов? Фактически, продуктом пользуется покупатель (и обнаруживает баг), проблема возникает по вине MQ (в рамках заявленной темы), а отдуваться должен продавец?
...
Это как вариант. Нужно ещё думать...
В идеале видится следующий вариант решения (вопрос в том, насколько он реализуем):
1- отключение в терминале опции автоматической установки обновлений, только сообщение о доступности и принятие решения самим пользователем (это уже где-то раньше предлагалось);
2- функция "откат до билда №..." в терминале.
Тогда в случае глюка советника, вызванного глюком нового билда, можно легко принять временные меры до разрешения ситуации с билдом. Особо осторожные могут в качестве дополнительной предосторожности обновления устанавливать в выходной день и прогонять в тестере своего советника. По адекватности или неадекватности отработки истории в сравнении с предыдущим билдом принимать окончательное решение в выборе обновление-откат.
При разработке (продаже) советника указывается билд на котором проверялась работоспособность.
В идеале видится следующий вариант решения (вопрос в том, насколько он реализуем):
1- отключение в терминале опции автоматической установки обновлений, только сообщение о доступности и принятие решения самим пользователем (это уже где-то раньше предлагалось);
2- функция "откат до билда №..." в терминале.
Тогда в случае глюка советника, вызванного глюком нового билда, можно легко принять временные меры до разрешения ситуации с билдом. Особо осторожные могут в качестве дополнительной предосторожности обновления устанавливать в выходной день и прогонять в тестере своего советника. По адекватности или неадекватности отработки истории в сравнении с предыдущим билдом принимать окончательное решение в выборе обновление-откат.
При разработке (продаже) советника указывается билд на котором проверялась работоспособность.
да, мне тоже кажется что это разумное предложение, (как сразу и предложил аналогичное tol64).
установка билда по требованию логичный выход. Защитит продавца и покупателя от разработчиков. :)
Продавец сможет более спокойно протестировать продукт на новом билде и выставить правки и новую версию по необходимости.
Просьба к разработчикам платформы - задуматься над этой темой и этому предложению в частности.
Может быть у компании есть свое видение проблемы и её решения?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Собственно вопрос этот назревал давно.
Ситуация следующая, вполне реальная.Программист и контроль маркета, протестировав софт, выкладывают его в маркете.
Конечно, больше всего в этой ситуации напрягает то, что будет страдать репутация программиста, нежели компании. Так как проблемы билда ведь нужно еще выявить и доказать.Покупатель, заплатив энную сумму за него, через некоторое время в новом билде обнаруживает, что продукт перестал работать.
Ок. Программист проверил и обнаружил, что проблема появилась в новом билде, но выявить место с багом и локализовать его нет возможности.
Что теперь делать трём сторонам?
Возвращать средства покупателю, которые возможно уже вложены в новые разработки?
Отправить покупателя к разработчикам терминала, сказав, что проблема в билде и это не вина программиста?
Или иной вариант?
За это время продукт получит массу негативных отзывов, и его, возможно, придется убрать с полки.
Получается, что программисты MQL зависят от разработчиков платформы. Причем зависят в такой мере, что любой финт в билде может испортить им репутацию на корню, или сорвать будущие заказы или другие планы.
В общем, какой выход из этой ситуации планируется и как компания может его решать?
ЗЫ. Пока что радует то, что компания развивается, и сама организует и поддерживает Маркет и продажу продуктов MQL5. Следовательно, борьба за качество будет, но кто будет платить за это своей репутацией и рублем?