市場：ビルドアップデート後の製品不具合はどのように処理されるのですか？

[---]

これは、実はずっと前から疑問だったんです。

状況は次のようなもので、かなりリアルです。

プログラマーと、その管理者が、ソフトウェアをテストした上で、マーケットに出す。
お客様は、ある程度の金額を支払って購入した後、しばらくして、その製品が新しい建物ではもう使えないことを知ります。
OKです。プログラマーが確認すると、新しいビルドに問題があることがわかるが、バグの場所を特定し、突き止める方法はない。

3党はこれからどうするのか？
新 開発のためにすでに投資されたかもしれない資金を購入者に返す？
購入者に「問題はビルドにあり、プログラマーの責任ではない」と端末の開発者に送りますか？
それとも別の方法？

もちろん、この状況で最もストレスになるのは、会社の評判よりもプログラマーの評判が落ちることだ。なぜなら、ビルドの問題点はまだ特定され、証明される必要があるからです。

この間、製品には多くの否定的な意見が寄せられ、棚から撤去されなければならないかもしれません。

つまり、MQLプログラマーは、プラットフォーム開発者に依存していることがわかります。しかも、依存度が高いので、作り方のトリックで根こそぎ評判を落としてしまったり、将来の注文や他の計画に支障をきたすこともあるのです。

一般に、このような状況からどのような出口を予定し、どのように解決していくのか。

ZS.今のところ、MQL5製品の開発と自社でのMarket・販売サポートを行っているのが良いところです。したがって、品質の争奪戦が繰り広げられることになるが、誰がその評判とお金を払うのだろうか。

[Anatoli Kazharski]

sergeev:
...

今のところ、開発が進んでいるのは良いことで、MQL5製品のMarketや販売を企画・支援しています。そのため、品質の争奪戦が繰り広げられることになるが、誰がその評判とお金を払うのだろうか。

質問は非常に適切です。そして、解決策を見出さなければならない。すでに提案があります。

例えば、次のようなことです。取引端末の 次のアップデート（ビルド）をインストールするかどうかは、ユーザー自身が判断する。つまり、新しいビルドを意識させつつ、いつインストールしてもいいように自分で判断できるようにしなければならないのです。アプリケーション開発者は、インストールされた端末のバージョンを2つ用意しなければならない。1つは以前のビルドを使ったバージョン、もう1つは最新のビルドを使ったバージョンです。製品を使用した際に新しいビルドでバグが発見されない場合、ベンダーは製品が最新のビルドに対応していることをマーケットに注記する。もし、最新のビルドで製品がバグを起こし始めたら、そのマークは付けられず、ユーザーは新しいビルドをインストールするのは時期尚早だと知ることになるのです。

これはオプションです。もっと考えることがある...

[михаил потапыч]

sergeev:

実は、この疑問はずっと前から抱いていた。

三者はこれからどうすればいいのか。

2つです。プログラマーは関係ない。購入者は、新市場のexをダウンロードできればよいのです。メール、リクエスト、キャプチャー、確認メッセージなどなしで。

もちろん、すでにオンになっているハードに限りますが。

[Renat Fatkhullin]

製品には社内でのバージョン管理機能があり、それについては記事（https://www.mql5.com/ru/articles/385）で紹介されています。

新しいバージョンがリリースされると、自動的にソフトウェアの更新を促すプロンプトが表示されます。2.xxのようなマイナーバージョンをアップグレードするのに適しています。

メジャーバージョンをリリースする場合、再販売できるように新しい製品を登録するか、既存のお客様には自動的な無償アップグレードで古い登録のまま新しいバージョンのリリースを継続する必要があります。

[---]

Renat:

製品は社内でバージョン管理されています。それについては、記事（https://www.mql5.com/ru/articles/385）をご覧ください。

新しいバージョンがリリースされると、自動的にアップデートのプロンプトが表示されます。2.xxのようなマイナーバージョンをアップグレードするのに適しています。

メジャーバージョンがリリースされた場合、新しい製品を再販売できるように登録する必要があります。また、既存のお客様には自動的に無償アップグレードを行い、旧登録で新しいバージョンのリリースを継続することもできます。

はい、これは新しいバージョンの製品に適用されるものです。

でもそれは、このスレッドの質問の内容とはちょっと違う。

端末の新規構築により、ソフトウェアの正常な動作が阻害される場合はどうでしょうか？

考えてみれば、月に2回くらいはビルドが出るわけです。 端末をバージョンアップすることで、お客様が2週間ほど製品を使えなくなることが判明する。 そういうことなんですね。

[---]

papaklass:
そればかりか、プログラマーは今の仕事をやめて、バグ取りに精を出すべきだろう。また、彼がいくつかの製品を市場に出している場合は？

だから、みんな面倒くさがり屋なんです。

でも、その解決策は？

[Andrey Dik]

sergeev:

しかし、その解決策は何だろうか？

は解決しない。

修正された新しいビルドが出るまで、製品は休眠状態になります。- とか言うと、端末のバグが修正された後、大勢のユーザーが憤慨して端末にバグを返せと要求するんだろうな(笑)。

[Yedelkin]

tol64:

製品を使用中に新しいビルドでバグが見つからなかった場合、ベンダーはマーケットプレイスで 製品を最新のビルドに対応させるようマーク します。最新ビルドで製品が「不具合」を起こし始めた場合、マーキングは行われず、ユーザーは新しいビルドをインストールするには時期尚早であることを知ることになります。

では、新しいビルドのバグをキャッチするのも、ベンダーの責任なのですか？実際、購入者が製品を使い（バグを発見し）、MQの責任で問題が発生し（記載されたトピック内で）、ベンダーが責任を負わなければならないのでしょうか？

[Anatoli Kazharski]

Yedelkin:
では、新しいビルドのバグをキャッチするのも、ベンダーの責任なのですか？実際、製品を購入者が使用し（バグを検出し）、その問題はMQの過失によって発生し（記載されたトピック内で）、ベンダーは責任を取らなければならないのか？

tol64 です。
...

それはオプションです。もっと考えることがある...

今のところ、これが唯一の選択肢／オファーです。しかも、一番便利・一番いいというわけでもない。

[Вангелис]

理想的には、次のような解が見えてきます（問題は、それがどの程度実現可能かです）。
1- 端末の自動更新インストールオプションを無効にし、可用性メッセージとユーザーによる決定のみにする（これは以前にもどこかで提案されたことがあります）。
2- "rollback to build #..." 機能をターミナルで実行します。
そうすれば、新規構築の不具合によるEAの不具合が発生した場合、構築状況が解消されるまでの一時的な対策が容易に行えるようになります。特に慎重な人は、念のため休日にアップデートをインストールし、テスターでEAを動かしてみるのもよいでしょう。前回のビルドと比較した履歴の妥当性・不充分性によって、アップデート・キャンセルを最終的に判断する。
Expert Advisorを開発（販売）する際には、その性能を検証したビルドを指定する必要があります。

[---]

Wangelys:

理想を言えば、次のような解答が見えてくる（問題は、それがどれだけ現実的かだ）。
1- 端末で自動的にアップデートをインストールするオプションを無効にし、利用可能性の報告のみを行い、ユーザーが判断する（これは以前にもどこかで提案されたことがある）。
2- "rollback to build #..." 機能をターミナルで実行します。
そうすれば、新規構築の不具合によるEAの不具合が発生した場合、構築状況が解消されるまでの一時的な対策が容易に行えるようになります。特に慎重な人は、念のため休日にアップデートをインストールし、テスターでEAを動かしてみるのもよいでしょう。前回のビルドと比較した履歴の妥当性・不充分性によって、アップデート・キャンセルを最終的に判断する。
Expert Advisorを開発（販売）する際には、その性能を検証したビルドを指定する必要があります。

そうですね、それは私も妥当な提案だと思います（tol64さんがすぐに同様の提案をされたので）。

オンデマンドでビルドをインストールするのは理にかなった方法です。売主と買主をデベロッパーから守ることができる。:)

販売者は、より静かに新しいビルドで製品をテストし、必要に応じて編集や新バージョンを公開することができるようになります。

私はプラットフォームの開発者に尋ねます - このトピックと特にこの提案について考えてみてください。

もしかして、会社独自の問題意識とその解決策を持っているのでは？