Mike Cohen
Top achievements
Rank 1
Rank 1
Mike Cohen
asked on 11 Jun 2010, 07:08 PM
Has anyone else found the level of changes to public members in each new release very frustrating?
I have a few developers working with the Calendar, GridView and Charts and with each new release we find ourselves spending a significant amount of time recreating templates because of breaking changes introduced by the latest binaries. We have customized the look of these controls to suit our needs and in many cases we found it necessary to provide our own template.
I've attached a screenshot of the Calendar after applying the 2010.1 603 release. I'd like to hear from others using this forum if you have had similar experiences.
Thanks,
Mike
5 Answers, 1 is accepted
0
Hello Mike,
Having in mind how many support tickets about fixing custom themes we get after every release, I could say that there are lots of developers that are in your situation. Unfortunately the bugfixes and the new features often require changes in the public API and the XAML, that inevitably lead to breaking the custom themes, especially for the large controls as Grid, Chart and Scheduler.
To slightly ease your lives we release beta versions of the new updates around a month before the release - this way we give you some time to try the changes and fix your themes. In addition, you could just send us your custom theme, that broke with the new release and we will try to fix it for you. On the other hand, sometimes the big changes in the controls lead to simpler themes (incompatible with the old, though) that are easier to customize - such case is the new RadScheduler that is under development right now. My rough estimate is to have five to ten times less XAML in the new themes, while keeping and improving the level of extensibility.
I would also like to get suggestions how to improve this process, since obviously we cannot stop the development just to prevent the custom themes from breaking :)
Best wishes,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Having in mind how many support tickets about fixing custom themes we get after every release, I could say that there are lots of developers that are in your situation. Unfortunately the bugfixes and the new features often require changes in the public API and the XAML, that inevitably lead to breaking the custom themes, especially for the large controls as Grid, Chart and Scheduler.
To slightly ease your lives we release beta versions of the new updates around a month before the release - this way we give you some time to try the changes and fix your themes. In addition, you could just send us your custom theme, that broke with the new release and we will try to fix it for you. On the other hand, sometimes the big changes in the controls lead to simpler themes (incompatible with the old, though) that are easier to customize - such case is the new RadScheduler that is under development right now. My rough estimate is to have five to ten times less XAML in the new themes, while keeping and improving the level of extensibility.
I would also like to get suggestions how to improve this process, since obviously we cannot stop the development just to prevent the custom themes from breaking :)
Best wishes,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Mike Cohen
Top achievements
Rank 1
Rank 1
answered on 15 Jun 2010, 04:16 PM
Unfortunately the bugfixes and the new features often require changes in the public API and the XAML, that inevitably lead to breaking the custom themes, especially for the large controls as Grid, Chart and Scheduler.
The notion that you must change the public API is simply not true. The WPF controls in the .NET Framework do not change. Most control vendors do not change their public APIs. Until moving to Telerik's components, we have used Infragistics for about 5 years. In that time we saw no change to their public API.
To slightly ease your lives we release beta versions of the new updates around a month before the release - this way we give you some time to try the changes and fix your themes.
The point is for us to not spend time redoing work we have already considered complete! Part of the reason you as a control vendor are able to make money selling controls is you save us time. Eventually this will end up costing us time. Each release we have moved to we have spent a couple of man days fixing our styles. This is far too expensive.
I would also like to get suggestions how to improve this process, since obviously we cannot stop the development just to prevent the custom themes from breaking
My suggestion: Stop thinking that you have to stop development if you are to stop introducing breaking changes. It simply isn't true. The controls in the System.Windows.Controls namespace do not change. Most other vendors do not change their public interface.
0
Hi Mike,
The notion that you must change the public API is simply not true.
You are right, but when the controls evolve, some APIs have to be replaced with more advanced ones, while other become obsolete because the related features do not need them anymore, etc. In addition, when a control has to receive dramatic changes because the requested features cannot be implemented with the current code base, we usually choose the optimal API for the new control according the developer feedback we received through the years. Of course, in such cases we try to provide temporary backwards compatible APIs to support the older versions for a while.
The WPF controls in the .NET Framework do not change.
This is true, but most of the WPF controls in the .NET Framework are very basic in comparison to RadScheduler, for example, and their feature sets does not change much across the releases. In addition, the .NET Framework is updated once in few years.
The point is for us to not spend time redoing work we have already considered complete!
You are right, but generally if you consider something complete, you should not upgrade its parts that might change over time. We provide bugfixes for older versions, so usually you are not forced to upgrade to a new major version with breaking changes because of existing bugs.
Regarding the RadScheduler theme that has been broken - it is our fault that we introduced a breaking change in a service pack release. This happens rarely, but sometimes we dont have a choice and I apologize for that. This specific problem is caused by a memory leak fix, that we introduced several weeks ago. A leaking property, holding a reference to RadScheduler was removed, hence the themes had to be updated in order to fix a couple of bindings to that property. I can provide more details about the memory leaks we fixed in the recent builds, if you are interested.
The changes in the theme are minor, so if you send us your XAML we will fix it immediately.
Regards,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
The notion that you must change the public API is simply not true.
You are right, but when the controls evolve, some APIs have to be replaced with more advanced ones, while other become obsolete because the related features do not need them anymore, etc. In addition, when a control has to receive dramatic changes because the requested features cannot be implemented with the current code base, we usually choose the optimal API for the new control according the developer feedback we received through the years. Of course, in such cases we try to provide temporary backwards compatible APIs to support the older versions for a while.
The WPF controls in the .NET Framework do not change.
This is true, but most of the WPF controls in the .NET Framework are very basic in comparison to RadScheduler, for example, and their feature sets does not change much across the releases. In addition, the .NET Framework is updated once in few years.
The point is for us to not spend time redoing work we have already considered complete!
You are right, but generally if you consider something complete, you should not upgrade its parts that might change over time. We provide bugfixes for older versions, so usually you are not forced to upgrade to a new major version with breaking changes because of existing bugs.
Regarding the RadScheduler theme that has been broken - it is our fault that we introduced a breaking change in a service pack release. This happens rarely, but sometimes we dont have a choice and I apologize for that. This specific problem is caused by a memory leak fix, that we introduced several weeks ago. A leaking property, holding a reference to RadScheduler was removed, hence the themes had to be updated in order to fix a couple of bindings to that property. I can provide more details about the memory leaks we fixed in the recent builds, if you are interested.
The changes in the theme are minor, so if you send us your XAML we will fix it immediately.
Regards,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Santosh kumar
Top achievements
Rank 1
Rank 1
answered on 16 Jun 2010, 11:18 PM
Of course, in such cases we try to provide temporary backwards compatible APIs to support the older versions for a while.
What does this mean? You will mark these APIs as deprecated and remove them later or you wont? Saying you "try to provide" isn't clear.
This is true, but most of the WPF controls in the .NET Framework are very basic in comparison to RadScheduler
Most? Perhaps that's true. The Grid is comparably complex. Further, there are many other vendors who manage without drastic changes.
You are right, but generally if you consider something complete, you should not upgrade its parts that might change over time.
I'm sorry but this is not a reasonable response. We have paid money for a maintenance contract and need new features and bug fixes.
We provide bugfixes for older versions, so usually you are not forced to upgrade to a new major version with breaking changes because of existing bugs.
This is news to me. Please show me where I can download hotfixes for specific bug fixes.
This specific problem is caused by a memory leak fix, that we introduced several weeks ago. A leaking property, holding a reference to RadScheduler was removed, hence the themes had to be updated in order to fix a couple of bindings to that property.
Why was it necessary to remove the property to fix the leak? Could it not have been converted to a dependency property or could the class not implement INotifyPropertyChanged?
Concerned,
Mike
0
Hi Mike,
I’m sorry to hear your frustration escalates on this matter. Please accept my sincere apologies! My only intention was only to provide you with more details on why these breaking changes occur. Maybe I missed to mention one more detail - 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 Silverlight 2. Now when Silverlight evolves we see the opportunity to make our controls more stable and better in the means of architecture and feature richness. 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.
Once again, please excuse us for all inconvenience caused!
Kind regards,
Hristo
the Telerik team
I’m sorry to hear your frustration escalates on this matter. Please accept my sincere apologies! My only intention was only to provide you with more details on why these breaking changes occur. Maybe I missed to mention one more detail - 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 Silverlight 2. Now when Silverlight evolves we see the opportunity to make our controls more stable and better in the means of architecture and feature richness. 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.
Once again, please excuse us for all inconvenience caused!
Kind regards,
Hristo
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items