Mark Griebling
Top achievements
Rank 1
Rank 1
Mark Griebling
asked on 18 May 2006, 01:33 AM
The Good: Quarterly releases
The Bad: Quarterly releases.
I really like the idea of Quarterly releases. However, I really don't like the implementation of them. I like the functionality upgrades that come with Quarterly releases, but I don't like the bugs that come with them. Given the complexity of cross-browser compatibility and the range of possible uses for the controls, I don't expect the quarterly releases to be bug free. However, I would like to see a better process for resolving outstanding bugs.
We use 8 of the controls in our application. To receive bug fixes I have to install all releases and hope there are no new bugs. Unfortunately, this is never the case as service packs now contain new functionality. I pray for a stable release so I can standardize on a set of controls before our product is released.
For customers to use controls in applications they have to be made stable in all features. I realize it is important to lead the industry, but since r.a.d. controls are sold as a suite, each release has to reach a point where all components are 'fixed'. This is especially important because the control's functionality are related. A customer cannot select the version for each control from different releases.
Don't get me wrong. I love the controls. They have saved me a lot of time and I appreciate the effort telerik puts into them. But when we deliver a product, our customers expect it to be bug free.
My suggestion is to only introduce new features with the Quarterly releases and use the service packs to resolve all reported bugs. This will allow customers to standardize on the control set version they want/need to use - freeing their time for development, not patching and learning new behavior.
Please, please, please consider my suggestion for future quarterly releases.
Thank you,
Mark Griebling
The Bad: Quarterly releases.
I really like the idea of Quarterly releases. However, I really don't like the implementation of them. I like the functionality upgrades that come with Quarterly releases, but I don't like the bugs that come with them. Given the complexity of cross-browser compatibility and the range of possible uses for the controls, I don't expect the quarterly releases to be bug free. However, I would like to see a better process for resolving outstanding bugs.
We use 8 of the controls in our application. To receive bug fixes I have to install all releases and hope there are no new bugs. Unfortunately, this is never the case as service packs now contain new functionality. I pray for a stable release so I can standardize on a set of controls before our product is released.
For customers to use controls in applications they have to be made stable in all features. I realize it is important to lead the industry, but since r.a.d. controls are sold as a suite, each release has to reach a point where all components are 'fixed'. This is especially important because the control's functionality are related. A customer cannot select the version for each control from different releases.
Don't get me wrong. I love the controls. They have saved me a lot of time and I appreciate the effort telerik puts into them. But when we deliver a product, our customers expect it to be bug free.
My suggestion is to only introduce new features with the Quarterly releases and use the service packs to resolve all reported bugs. This will allow customers to standardize on the control set version they want/need to use - freeing their time for development, not patching and learning new behavior.
Please, please, please consider my suggestion for future quarterly releases.
Thank you,
Mark Griebling
3 Answers, 1 is accepted
0
Hello Mark,
Thank you for your feedback. You definitely have some very good points in your comments.
Generally, we do provide mainly fixes in our Service Packs while major new functionality is introduced with the Quarterly Releases. However, this is not always the case and we are sometimes introducing new features in Service Packs as well. There are some quite reasonable explanations for doing this.
We are doing our best to stay on top of new things and bring new technologies to our customers as quickly as possible and sometimes waiting for the next Q release is not the best option. This has been the case with our "Atlas" Service Pack. One of our top priorities over the past months has been to provide powerful AJAX features. Soon after our Q1 release Microsoft "Atlas" team has shipped a stable CTP with a GoLive license which we have been waiting for some time. We acted really quickly and led by the numerous requests we have received for "Atlas" interoperability for r.a.d.controls we shipped an Interim Release which included not only fixes (as a regular Service Pack) but major new functionality as well. As a result we were the first component vendor to provide this new feature on the market.
Additionally, customer requests have always been a major factor in our release plans. We very often see suggestions and ideas from telerik community which become quite popular and quickly pick-up interest. The more requests we receive on a specific new feature from you the higher priority it has in our ToDo lists. So there are a few cases in which we have introduced small new features and enhancements in Service Packs in order to fit the quickly evolving requirements of our customers. Sometimes it proves much better for all of us to bring out new functionality in a Service Pack (as long as it does not require a major change on our side and is backwards compatible on your side) than to wait another couple of months before it gets to the customers.
New features and short release cycles are not something you should be afraid of. Telerik community really likes the frequency of our updates and we are especially proud of the fact that we are one of the fastest component vendors to bring functionality upgrades on the market and to develop its products. We do our best to cover most of our development with automated tests and we make sure we fix all issues during internal rounds of QA so that everything which gets to you is of top quality. Of course there are some cases in which we fail to find all bugs and something slips out. Then all reported problems immediately get higher priority than any new features currently in the pipeline.
What we see as a weakness is that sometimes we introduce breaking changes when it is simply not the right time (say for a minor update when you expect only bugfixes and full backwards compatibility). We understand that this is a problem on our side and we have several internal initiatives running to ensure we address these weak points (backwards compatibility and number of bugs)
Your suggestions are highly appreciated and we do believe that we will find the best approach and will provide you with the most stable toolset for ASP.NET development.
We would be very happy to hear more comments on telerik Quarterly Releases, Functionality Updates and Service Packs. Please let us know what we can do better.
Kind Regards,
Ivo Nedkov
the telerik team
www.telerik.com | dnn.telerik.com | www.sharepointcontrols.com | www.sitefinity.com | www.mcmscontrols.com
Thank you for your feedback. You definitely have some very good points in your comments.
Generally, we do provide mainly fixes in our Service Packs while major new functionality is introduced with the Quarterly Releases. However, this is not always the case and we are sometimes introducing new features in Service Packs as well. There are some quite reasonable explanations for doing this.
We are doing our best to stay on top of new things and bring new technologies to our customers as quickly as possible and sometimes waiting for the next Q release is not the best option. This has been the case with our "Atlas" Service Pack. One of our top priorities over the past months has been to provide powerful AJAX features. Soon after our Q1 release Microsoft "Atlas" team has shipped a stable CTP with a GoLive license which we have been waiting for some time. We acted really quickly and led by the numerous requests we have received for "Atlas" interoperability for r.a.d.controls we shipped an Interim Release which included not only fixes (as a regular Service Pack) but major new functionality as well. As a result we were the first component vendor to provide this new feature on the market.
Additionally, customer requests have always been a major factor in our release plans. We very often see suggestions and ideas from telerik community which become quite popular and quickly pick-up interest. The more requests we receive on a specific new feature from you the higher priority it has in our ToDo lists. So there are a few cases in which we have introduced small new features and enhancements in Service Packs in order to fit the quickly evolving requirements of our customers. Sometimes it proves much better for all of us to bring out new functionality in a Service Pack (as long as it does not require a major change on our side and is backwards compatible on your side) than to wait another couple of months before it gets to the customers.
New features and short release cycles are not something you should be afraid of. Telerik community really likes the frequency of our updates and we are especially proud of the fact that we are one of the fastest component vendors to bring functionality upgrades on the market and to develop its products. We do our best to cover most of our development with automated tests and we make sure we fix all issues during internal rounds of QA so that everything which gets to you is of top quality. Of course there are some cases in which we fail to find all bugs and something slips out. Then all reported problems immediately get higher priority than any new features currently in the pipeline.
What we see as a weakness is that sometimes we introduce breaking changes when it is simply not the right time (say for a minor update when you expect only bugfixes and full backwards compatibility). We understand that this is a problem on our side and we have several internal initiatives running to ensure we address these weak points (backwards compatibility and number of bugs)
Your suggestions are highly appreciated and we do believe that we will find the best approach and will provide you with the most stable toolset for ASP.NET development.
We would be very happy to hear more comments on telerik Quarterly Releases, Functionality Updates and Service Packs. Please let us know what we can do better.
Kind Regards,
Ivo Nedkov
the telerik team
www.telerik.com | dnn.telerik.com | www.sharepointcontrols.com | www.sitefinity.com | www.mcmscontrols.com
0
Michael Hanson
Top achievements
Rank 1
Rank 1
answered on 03 Jul 2006, 09:23 AM
I would like to add something to this conversation.
Microsoft have provided mechanisms within the .NET languages that allow you to mark features as depracated or obsolete, but leave them in working order. If these features are used correctly, the .NET compilers will throw warnings and/or errors at build time informing developers of features they should be changing, but their existing applications will not break.
Your current practice with service packs and updates means we, your customers are presented with two choices, either maintain multiple copies of the controls on our systems, with all the headaches that go with that, or waste precious time modifying existing applications every time you release an update that breaks them.
We buy tools like your control suite to improve our productivity, as well as the quality of systems we implement, but we lose the increased productivity element because of the time we have to waste updating existing applications or maintaining multiple versions.
A case in point is your latest release of RadMenu Q2 2006. Some of the changes you made were quite radical, and imho they were appropriate changes. However you removed features that were in previous versions so we are forced to make choices we should not have to make. The correct thing for you to have done was mark the features you removed as depracated (and then in a future release mark them as obsolete, before eventually removing them) so that existing applications would continue to work when compiled and the reference is updated with the new DLL replacing the old one. It takes less effort to assign the attribute to a method or property of a control that marks it as depracated or obsolete than it does to remove the code, and you would have a much happier customer base if you adopted this practice.
Microsoft have provided mechanisms within the .NET languages that allow you to mark features as depracated or obsolete, but leave them in working order. If these features are used correctly, the .NET compilers will throw warnings and/or errors at build time informing developers of features they should be changing, but their existing applications will not break.
Your current practice with service packs and updates means we, your customers are presented with two choices, either maintain multiple copies of the controls on our systems, with all the headaches that go with that, or waste precious time modifying existing applications every time you release an update that breaks them.
We buy tools like your control suite to improve our productivity, as well as the quality of systems we implement, but we lose the increased productivity element because of the time we have to waste updating existing applications or maintaining multiple versions.
A case in point is your latest release of RadMenu Q2 2006. Some of the changes you made were quite radical, and imho they were appropriate changes. However you removed features that were in previous versions so we are forced to make choices we should not have to make. The correct thing for you to have done was mark the features you removed as depracated (and then in a future release mark them as obsolete, before eventually removing them) so that existing applications would continue to work when compiled and the reference is updated with the new DLL replacing the old one. It takes less effort to assign the attribute to a method or property of a control that marks it as depracated or obsolete than it does to remove the code, and you would have a much happier customer base if you adopted this practice.
0
Hello Michael,
Thank you very much for sharing your points. They are much appreciated.
Our main goals in building r.a.d.controls are to reduce your development time, increase your productivity and help you "deliver more than expected" in terms of UI. Let me assure you that the new version of r.a.d.menu (v4.0) has been developed only with our customers in mind and every single line of code we have written is intended to make things much easier for you.
Indeed we use the .NET mechanisms for providing deprecated and obsolete properties especially in our Service Packs and minor updates. However when introducing a completely new rewrite of a product these mechanisms do not prove very efficient.
Unfortunately, we are facing tough choices especially with new versions our "oldest" products (r.a.d.editor, r.a.d.menu, etc have been around for about 4 years now). When these controls were initially designed .NET programming was very different from today and if we want to stay at the top of the control vendors' offering we inevitably need to make big changes. One such change is introduced in the new version of r.a.d.menu.
The previous architecture and design of the menu control had reached its limits and could not be extended any more without a serious hit on performance and efficiency. That is why we took the road of almost 100% code rewrite and launched the next generation of our r.a.d.menu. We are very proud of the new semantic implementation which now renders with list items and thus tremendously reducing the HTML output by more than 70%. Except for the significantly improved footprint and performance r.a.d.menu v4.0 now introduces powerful DataBinding capabilities, extended VS.NET Design-Time support, very easy to use single-property skinning mechanism, a variety of expand/collapse animation effects as well as an richer client-side API closely matching the server-side API. Needless to say these new improvements would not have been so impressive if we were to leave the old somewhat cumbersome logic and mark properties as deprecated or obsolete.
We are doing our best to prepare customers for the transition to the new version and have provided thorough migration guides with our documentation (Online Version). We have also shipped an early beta version so that we could get as much feedback as possible and put it into production code. So far the general reaction from our customer base is very positive and all developers are excited to try the new version of r.a.d.menu. (This same approach was used in our tab control rewrite last quarter and we are now seeing many happy customers of r.a.d.tabstrip v3.x.)
On behalf of the r.a.d.menu team at telerik I do apologize for the time you will need to migrate your current projects to the new version but I believe that in the long term the new r.a.d.menu will prove much better for everyone.
Once again I wish to thank you for the feedback and we will definitely have it in mind when we implement breaking changes across our product line.
Regards,
Ivo
the telerik team
Thank you very much for sharing your points. They are much appreciated.
Our main goals in building r.a.d.controls are to reduce your development time, increase your productivity and help you "deliver more than expected" in terms of UI. Let me assure you that the new version of r.a.d.menu (v4.0) has been developed only with our customers in mind and every single line of code we have written is intended to make things much easier for you.
Indeed we use the .NET mechanisms for providing deprecated and obsolete properties especially in our Service Packs and minor updates. However when introducing a completely new rewrite of a product these mechanisms do not prove very efficient.
Unfortunately, we are facing tough choices especially with new versions our "oldest" products (r.a.d.editor, r.a.d.menu, etc have been around for about 4 years now). When these controls were initially designed .NET programming was very different from today and if we want to stay at the top of the control vendors' offering we inevitably need to make big changes. One such change is introduced in the new version of r.a.d.menu.
The previous architecture and design of the menu control had reached its limits and could not be extended any more without a serious hit on performance and efficiency. That is why we took the road of almost 100% code rewrite and launched the next generation of our r.a.d.menu. We are very proud of the new semantic implementation which now renders with list items and thus tremendously reducing the HTML output by more than 70%. Except for the significantly improved footprint and performance r.a.d.menu v4.0 now introduces powerful DataBinding capabilities, extended VS.NET Design-Time support, very easy to use single-property skinning mechanism, a variety of expand/collapse animation effects as well as an richer client-side API closely matching the server-side API. Needless to say these new improvements would not have been so impressive if we were to leave the old somewhat cumbersome logic and mark properties as deprecated or obsolete.
We are doing our best to prepare customers for the transition to the new version and have provided thorough migration guides with our documentation (Online Version). We have also shipped an early beta version so that we could get as much feedback as possible and put it into production code. So far the general reaction from our customer base is very positive and all developers are excited to try the new version of r.a.d.menu. (This same approach was used in our tab control rewrite last quarter and we are now seeing many happy customers of r.a.d.tabstrip v3.x.)
On behalf of the r.a.d.menu team at telerik I do apologize for the time you will need to migrate your current projects to the new version but I believe that in the long term the new r.a.d.menu will prove much better for everyone.
Once again I wish to thank you for the feedback and we will definitely have it in mind when we implement breaking changes across our product line.
Regards,
Ivo
the telerik team