Hi Telerik support,
We have been evaluating your WPF controls on and off over the last year or so with a view to putting together a large app that would use a large number of them. I have to say that as of the last update we are on the verge of throwing in the towel in frustration at incessant changes to interfaces, class depreciations and general usage changes to the controls.
From a quick search in this forum:
May 2007, in answer to exactly the same complaint:
Well, sorry, but as far as I can see you have introduced breaking changes on pretty much every single release.
I had assumed when we first started the trial that the product line was young and thus the interfaces might take a little time to settle down, but the changes show no sign of settling down over a year later (and 4 years after your comment!) and require our code to be rewritten, often in non-trivial ways.
We all appreciate the need for change, but there are limits and there has to be a balance between functionality and interface stability. I think there has been plenty of time to get much of this right by now, surely?
How does everyone else justify additional code fix/rewrite and QA time to the business every time they need to upgrade the telerik controls to fix a bug or implement a new feature released in the telerik control set? Am I to assume that we cannot upgrade the telerik controls without major rewrites of our code?
You guys have a great product and I hope you take this as constructive criticism but you have more competitors now than ever and I actually want to go on and purchase from you; but we are reviewing competitors again because you are giving us no choice. Given your statement before and what we have seen since I hope you can offer something more concrete than 'general policy' statements.
I would love to hear what telerik and other forum users feel about this.
We have been evaluating your WPF controls on and off over the last year or so with a view to putting together a large app that would use a large number of them. I have to say that as of the last update we are on the verge of throwing in the towel in frustration at incessant changes to interfaces, class depreciations and general usage changes to the controls.
From a quick search in this forum:
May 2007, in answer to exactly the same complaint:
It is a general policy at Telerik to only introduce breaking changes when the benefits of the new version significantly outweigh the disadvantages of not having a straightforward upgrade process. Nevertheless, in the rare cases when breaking changes are introduced we do our best to thoroughly document all changes and encourage customers to go through the "Changes and backwards compatibility" articles before upgrading to a new major versionWell, sorry, but as far as I can see you have introduced breaking changes on pretty much every single release.
I had assumed when we first started the trial that the product line was young and thus the interfaces might take a little time to settle down, but the changes show no sign of settling down over a year later (and 4 years after your comment!) and require our code to be rewritten, often in non-trivial ways.
- Solutions to relatively simple problems often rely on overriding templates which then get radically changed
- Properties become 'read only' - presumably the thinking is that this softens the blow. It does not.
- Properties get renamed (I can live with this one so long as it's just a rename and semantics not changed as well)
- Class depreciated. Not much fun if you were overriding these or using the events.
- etc.
We all appreciate the need for change, but there are limits and there has to be a balance between functionality and interface stability. I think there has been plenty of time to get much of this right by now, surely?
How does everyone else justify additional code fix/rewrite and QA time to the business every time they need to upgrade the telerik controls to fix a bug or implement a new feature released in the telerik control set? Am I to assume that we cannot upgrade the telerik controls without major rewrites of our code?
You guys have a great product and I hope you take this as constructive criticism but you have more competitors now than ever and I actually want to go on and purchase from you; but we are reviewing competitors again because you are giving us no choice. Given your statement before and what we have seen since I hope you can offer something more concrete than 'general policy' statements.
I would love to hear what telerik and other forum users feel about this.
1 Answer, 1 is accepted
0
Hello Philip,
I am sorry to hear about your frustration while using our RadControls for WPF.
We are constantly working on improving our controls. Unfortunately the bugfixes and the new features often require changes in the public API and the XAML. One very important detail about why these changes occur is the fact that our WPF and Silverlight controls share the same codebase. It is obvious that WPF is more mature and stable but when we started developing our Silverlight suite we took the tough decision to develop both suites on the same pace and with exactly the same functionality for both platforms. This is why for some of the features we carry heavy legacy from previous Silverlight versions. When Silverlight evolves we see the opportunity to make our controls more stable and better in the means of architecture and feature richness. Another major factor for such changes are the clients' requests for new features - with each new release the demand for complex scenarios increases.
Sometimes it appears that the best way to address these is a total rework of a given part rather than trying to “patch” it. All of us here at Telerik, are fully aware what problems this is causing to our clients and how frustrated they are when they get the new version and it introduces some major changes in the public API.
We try to keep these changes to the possible minimum but in these rare cases we provide obsolete properties and methods, and we keep them for one release cycle (around four months). Unfortunately if you use obsolete properties, there will be no warnings and you will get errors when we delete the properties. This is why we are doing our best to provide detailed release history where all changes are listed, blog posts which give more explanations how the new features should be used, Latest Internal Build each Friday to provide an early preview of what is coming with the next SP or official release. Furthermore we provide full assistance to all clients with custom scenarios and we dedicate a special attention for each case.
I hope we can get your understanding on this matter and be sure that each time you face some problem or need our assistance we will be happy to do our best to help you.
Regards,
Hristo
Unit Manager
the Telerik team
I am sorry to hear about your frustration while using our RadControls for WPF.
We are constantly working on improving our controls. Unfortunately the bugfixes and the new features often require changes in the public API and the XAML. One very important detail about why these changes occur is the fact that our WPF and Silverlight controls share the same codebase. It is obvious that WPF is more mature and stable but when we started developing our Silverlight suite we took the tough decision to develop both suites on the same pace and with exactly the same functionality for both platforms. This is why for some of the features we carry heavy legacy from previous Silverlight versions. When Silverlight evolves we see the opportunity to make our controls more stable and better in the means of architecture and feature richness. Another major factor for such changes are the clients' requests for new features - with each new release the demand for complex scenarios increases.
Sometimes it appears that the best way to address these is a total rework of a given part rather than trying to “patch” it. All of us here at Telerik, are fully aware what problems this is causing to our clients and how frustrated they are when they get the new version and it introduces some major changes in the public API.
We try to keep these changes to the possible minimum but in these rare cases we provide obsolete properties and methods, and we keep them for one release cycle (around four months). Unfortunately if you use obsolete properties, there will be no warnings and you will get errors when we delete the properties. This is why we are doing our best to provide detailed release history where all changes are listed, blog posts which give more explanations how the new features should be used, Latest Internal Build each Friday to provide an early preview of what is coming with the next SP or official release. Furthermore we provide full assistance to all clients with custom scenarios and we dedicate a special attention for each case.
I hope we can get your understanding on this matter and be sure that each time you face some problem or need our assistance we will be happy to do our best to help you.
Regards,
Hristo
Unit Manager
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get now >>