市场：在构建更新后，如何处理产品故障的情况？
...
到目前为止，好消息是，公司正在开发，并组织和支持MQL5产品的市场和销售。因此，将有一场对质量的争夺，但谁会用自己的名誉和金钱来买单？
这些问题很有意义。而且必须找到一个解决方案。我已经有了一个建议。
例如，你可以做以下工作。为了安装交易终端 的下一个更新（构建），用户自己决定是否安装它。换句话说，你必须让他/她知道新的建设，但能够自己决定他/她什么时候可以安装它。这样，应用程序开发人员必须有两个版本的安装终端。一个版本是以前的构建，另一个版本是最新的构建。如果在使用产品时没有发现新版本中的错误，那么供应商就会在市场中注明该产品与最新版本兼容。如果产品在最新的版本中开始出现错误，标记就不会放在那里，用户会知道现在安装新版本还为时过早。
这也是一种选择。更多需要思考的问题...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
事实上，这个问题已经酝酿了很久了。
三方现在应该怎么做？
二。程序员与此毫无关系。买方只需要能够下载新的市场前。没有电子邮件、请求、验证码、确认信息等。
当然，只是在硬件上，它已经在那里了。
产品有一个内部版本功能，你可以在文章中读到https://www.mql5.com/ru/articles/385。
当新版本发布时，会有一个自动提示来更新软件。这对升级次要版本（如2.xx）很有好处。
当发布主要版本时，你需要注册一个新的产品，以便能够重新销售或在旧的注册下继续发布新的版本，并为现有客户提供自动免费升级。
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
产品有一个内部版本，你可以在文章中读到https://www.mql5.com/ru/articles/385。
当新版本发布时，会有一个自动提示来更新软件。这对升级次要版本（如2.xx）是很好的。
当主要版本发布时，你需要注册新的产品，以便能够重新销售或在旧的注册下继续发布新的版本，并为现有客户提供自动免费升级。
是的，这就是适用于新版本产品的内容。
但这与主题中的问题有点不同。
如果新构建的终端阻碍了软件的正常运行，怎么办？
如果你想一想，构建的产品大约一个月出两次。 事实证明，通过升级终端，客户将在几个星期内失去使用该产品的能力。 这就是我们正在谈论的问题。
不仅如此，程序员应该辞去目前的工作，忙着去抓这个错误。如果他在市场上有几个产品呢？
所以他们都得到了麻烦。
但解决方案是什么呢？
但解决方案是什么呢？
没有解决办法。
在有新的修复方案之前，产品将一直处于闲置状态（或者对客户来说是赔钱，甚至可能是盈利--谁知道呢？- 然后在终端错误被修复后，一群用户会愤然要求将该错误带回终端？)
如果在使用产品时没有发现新版本中的错误，供应商将在市场上把 产品标记 为与最新版本兼容。如果产品在最新版本上开始出现 "故障"，则不做任何标记，用户会知道现在安装新版本为时过早。
因此，供应商也要负责在新的构建中捕捉错误？事实上，产品被买方使用（并检测到一个错误），问题的发生是由于MQ的错误（在陈述的主题内），而供应商必须承担责任？
...
这也是一个选择。更多需要思考的问题...
理想情况下，我们看到以下解决方案（问题是它的可行性如何）。
1- 在终端中禁用自动更新安装选项，只有可用性信息和用户的决定（这在以前的某个地方被建议过）。
2- "rollback to build #... "函数在终端。
那么在发生由新的构建故障引起的EA故障时，可以很容易地采取临时措施，直到构建情况得到解决。特别谨慎的人可以，作为额外的预防措施，在休息日安装更新，并在测试器中运行他们的EA。通过与以前的建设相比，历史的充分或不足，做出是否更新-取消的最终决定。
当开发（销售）一个专家顾问时，你应该指定其性能已被测试的构建。
理想情况下，我们看到以下解决方案（问题是它的现实性如何）。
1- 在终端中禁用自动安装更新的选项，只报告可用性并由用户做出决定（这在以前的某个地方已经建议过了）。
2- "rollback to build #... "函数在终端。
那么在发生由新的构建故障引起的EA故障时，可以很容易地采取临时措施，直到构建情况得到解决。特别谨慎的人可以，作为额外的预防措施，在休息日安装更新，并在测试器中运行他们的EA。通过与以前的建设相比，历史的充分或不足，做出是否更新-取消的最终决定。
当开发（销售）一个专家顾问时，你应该指定其性能已被测试的构建。
是的，这对我来说也是一个合理的建议，（正如一个类似的tol64立即建议的那样）。
按需安装构建是合理的出路。将保护卖家和买家免受开发商的影响。:)
卖方将能够更安静地在新的构建上测试产品，并在必要时暴露出编辑和新版本。
我请平台的开发者们--考虑一下这个话题，特别是这个建议。
也许公司对问题及其解决方案有自己的看法？
其实这个问题已经存在很长时间了。
情况如下，相当真实。程序员和市场的控制者，在测试了软件后，将其放在市场上。
当然，这种情况下最令人紧张的是，程序员的声誉将比公司的声誉受到更大的影响。因为建设的问题仍然需要被确认和证明。客户在支付了一定的费用后，一段时间后发现该产品在新的建筑中不能再使用了。
好的。程序员检查后发现问题出现在新的构建中，但没有办法定位和找出这个错误。
三方现在做什么？
将 可能已经投资于新开发项目的资金返还 给买方？
把买家送到终端的开发者那里，说问题在构建中，不是程序员的错？
或另一种方式？
在这段时间里，该产品会得到很多负面反馈，可能不得不下架。
因此，事实证明，MQL程序员是依赖于平台开发者的。而且他们的依赖性很强，在建设中的任何花招都会毁掉他们在根基上的声誉，或者扰乱未来的订单或其他计划。
总的来说，在这种情况下，计划采取什么样的出路，公司如何解决这个问题？
到目前为止，好消息是，该公司正在开发并自己组织和支持MQL5产品的市场和销售。因此，将有一场质量之争，但谁会用自己的名誉和金钱来买单？