Market: How will situations of product failure be handled after a build update ?
...
So far, the good news is that the company is developing, and it organizes and supports the Market and sale of MQL5 products. Therefore, there will be a struggle for quality, but who will pay for it with their reputation and money?
The questions are very relevant. And a solution must be found. I already have a suggestion.
For example, you could do the following. To install the next update (build) for the trading terminal, the user himself decides whether to install it or not. In other words, you have to make him/her aware of the new build but be able to decide for himself/herself when he/she may install it. Application developers must then have two versions of the installed terminal. One version with the previous build, and a second version with the latest build. If no bugs are found in the new build when using the product, the vendor makes a note in the Market that the product is compatible with the latest build. If the product begins to go buggy in the latest build, the marking will not be put there and the user will know that it is too early to install the new build.
This is an option. More to think about...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
In fact, this question has been brewing for a long time.
What should the three parties do now?
Two. The programmer has nothing to do with it. The buyer simply needs to be able to download the new market ex. Without emails, requests, captchas, confirmation messages, etc.
Of course, only on the hardware, where it is already on.
The products have an in-house versioning feature, you can read about it in the article https://www.mql5.com/ru/articles/385.
When a new version is released there will be an automatic prompt to update the software. This is good for upgrading minor versions such as 2.xx
When releasing major versions, you will need to register the new product to be able to re-sell or continue releasing new versions under the old registration with an automatic free upgrade for existing customers.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
The products have an in-house versioning, you can read about it in the article https://www.mql5.com/ru/articles/385
When a new version is released, there will be an automatic prompt to update the software. This is good for upgrading minor versions such as 2.xx
When major versions are released, you will need to register the new product to be able to re-sell or continue releasing new versions under the old registration with an automatic free upgrade for existing customers.
Yes, this is what applies to new versions of the products.
But that's a bit different to what the question in the thread is about.
What about if the new build of the terminal blocks the normal operation of the software?
If you think about it, the builds come out about twice a month. It turns out that by upgrading the terminal, the customer will lose the ability to use the product for a couple of weeks. That's what we're talking about.
Not only that, the programmer should quit his current job and get busy catching the bug. And if he has several products in the market?
So they all get the hassle.
But what's the solution?
but what could be the solution?
there is no solution.
Until there is a new build with the fixes, the product will remain idle (or lose money to the customer, or maybe even profit - who knows? - then after the terminal bug is fixed, a crowd of users will indignantly demand that the bug be returned to the terminal?)
If no bugs are found in the new build while using the product, the vendor will mark the product in the Marketplace as compatible with the latest build. If the product starts to "glitch" on the latest build, no marking is made and the user will know that it is too early to install the new build.
So the vendor is also responsible for catching bugs in new builds? In fact, the product is used by the buyer (and detects a bug), the problem occurs through the fault of MQ (within the stated topic), and the vendor has to take the blame?
...
That's an option. More to think about...
Ideally, we see the following solution (question is how feasible it is):
1- Disable automatic update installation option in the terminal, only availability message and decision by user (this has been suggested somewhere before);
2- "rollback to build #..." function in the terminal.
Then in the event of an EA glitch caused by a new build glitch, temporary measures can easily be taken until the build situation is resolved. Particularly cautious ones can, as an extra precaution, install updates on a day off and run their EA in the tester. By the adequacy or inadequacy of the history compared to the previous build, make the final decision whether to update-cancel.
When developing (selling) an Expert Advisor, you should specify the build on which its performance has been tested.
Ideally, we see the following solution (the question is how realistic it is):
1- Disabling the option to automatically install updates in the terminal, only reporting availability and making the decision by the user (this has been suggested somewhere before);
2- "rollback to build #..." function in the terminal.
Then in the event of an EA glitch caused by a new build glitch, temporary measures can easily be taken until the build situation is resolved. Particularly cautious ones can, as an extra precaution, install updates on a day off and run their EA in the tester. By the adequacy or inadequacy of the history compared to the previous build, make the final decision whether to update-cancel.
When developing (selling) an Expert Advisor, you should specify the build on which its performance has been tested.
yes, that seems like a reasonable suggestion to me too, (as a similar one tol64 suggested immediately).
Installing a build on demand is the logical way out. Will protect the seller and the buyer from the developers. :)
The seller will be able to more quietly test the product on the new build and expose the edits and the new version, if necessary.
I ask the developers of the platform - think about this topic and this proposal in particular.
Maybe the company has its own vision of the problem and its solution?
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
This has actually been a question for a long time.
The situation is as follows, quite real.The programmer and the control of the marketplace, having tested the software, put it on the marketplace.
Of course, the most stressful part of this situation is that the programmer's reputation will suffer more than that of the company. Because the problems of the build still need to be identified and proven.The customer, after paying a certain amount of money for it, finds out some time later that the product does not work anymore in the new build.
OK. The programmer checks and finds that the problem is in the new build, but there is no way to locate and locate the bug.
What do the three parties do now?
Return the funds to the buyer that may have already been invested in the new development?
Send the buyer to the developers of the terminal saying that the problem is in the build and it is not the programmer's fault?
Or another way?
The product will get a lot of negative feedbacks during this time and it may have to be removed from the shelf.
So it turns out that MQL programmers are dependent on the platform developers. And they are so dependent that any trick in the build can ruin their reputation at the roots, or disrupt future orders or other plans.
In general, what way out of this situation is planned and how can the company solve it?
ZS. So far the good news is that the company is developing and itself organizes and supports the Market and sale of MQL5 products. Therefore, there will be a fight for quality, but who will pay for it with their reputation and money?