Thank you for contacting us.
You put forward some interesting discussion topics and we would love to see what the Telerik community thinks of them. I will try to address the more specific questions you have to give you an insight of why we do things the way we do.
List of known bugs for each version visible for licensed customers
This is in the works. Dubbed as Public Issue Tracking System, it will offer a list of known issues which our customers can review at their leisure. Not only we will list all known issues, but we will also list the features you guys have requested from us.
The system will give you the ability to vote for bugs and feature requests, which will directly impact our decision making process, because we will have a better way of tracking what's the most important bug we will need to address, or the most important feature that our clients would like to see in the next major release. We hope that the Public Issue Tracking System will provide more details on what are working on and will make our job more transparent. The time frame for this is early next year.
High frequency of service pack releases relative to a major release
Our release is as follows: we have three major releases per year, and we provide at least on service pack per major release. If the major releases are 2-3 months apart (short release cycle) we usually ship just one SP. If the time between major releases is 3-4 months (large release cycle) we provide two service packs. If there are showstopper issues in any release, we may provide more service packs to address the problems, however we seldom get to three service pack per major release.
Furthermore, if a customer reports an issue that he thinks is a showstopper for his work, and if we think that the issue has a fairly large impact, we will provide him/her with a custom build, addressing this particular issue. Although this is not a practice we would like to enforce publically (ideally there should not be such issues), we try to get the customer going by helping him out as fast we can.
Unfortunately, such unplanned custom builds usually take considerable amount of time to test and prepare relative to the amount of fix(es) it offers. So the line of whether to provide a custom build or not is very thin, especially towards the end of a major release. We take into consideration our plans for a particular release, time frame till next release, what our customer's expectations are, etc. before we make such decisions.
This said, Telerik has always taken pride of its release schedule, and most of our customers think of it as being aggressive. History shows
that we have 3 major releases per year, at least one SP per release,
and a minimum of 1 custom build per release, for a minimum of 9 releases per year, which is a duration of 1.5 months per release. Some of our competitors are not able to match this release cycle, at least not for the competitive price we sell our products at.
Still, your opinion seems to differ from the common perception and I will be happy to hear your thoughts on how we can further improve our release schedule to meet your needs.
No introduction of new features or heavy refactoring in service packs
I agree with you totally on this one and it has always been our priority to introduce as little breaking changes as possible in major releases, and none in minor releases. However, as with all software, things evolve: new technologies and methodologies emerge, there are shifts in customer requirements and expectations, code needs to be optimized, performance need to be improved, etc. These are all valid business reasons to do something differently than we did it 3 years ago, so that we can introduce new features and products, and keep our customers happy (and ultimately stay in business). This however has to be true only for major releases and this is what we do - we do not have breaking changes in service packs and if do, we will glady fix them right away. We also stay away of doing refactoring in minor versions, becuase it is bad practice.
If we are to introduce breakign changes, we mark the old properties and methods as obsolete so that our customers can respond to the changes. Our policy is to support obsolete properties and methods for at least
one major release, however since this is a bit short in the WinForms
world, we usually support them for 2 or 3 major releases, depending on
the impact of the change(s).
There is one very important factor which has direct impact on such changes - customer expectations and demands. If we are pushed to introduce a major fix or a feature request in a service pack, say from an enterprise customer, and if the change is fairly minor, i.e. it will not impact the majority of our customers, the chances are that that we will do it - otherwise it will be pushed in a custom build or a major release. Our focus has always been to keep the customers happy and we are following this policy closely.
Ongoing support and bug fixes for each released major release for at
least a year, so that we can get bug fixes without being forced to
upgrade to new feature releases
We operate in a very intense, competitive and fast-moving environment. We need to be able to provide rapid responses to our customers, both in terms of technical support and new features. We need to be able to stay ahead, or at least in par, with the competition. Since we have limited resources (in terms of developer time, release schedule, etc), we prefer to focus on fixing, improving and providing value to the widest range of customers in the shortest possible release cycle.
I understand your concern and I am sure that support for older versions will be greatly appreciated by you guys, but at what cost? On prima vista it seems that we will have to support at least 4 code bases (three for the last three major releases + one for the next major version) which is very hard. Even if we support old versions and provide custom builds, there is no
way of knowing that you would not hit another issue which was
consequitively fixed, which makes the bug fixing process unusually complicated and time-consuming. Generally speaking, we would not mind doing this, however this will impact the price of our tools considerably. From this standpoint, we prefer to focus on continuous quality improvements and to offer more service packs, than to support several code bases.
As to bugs - we
have nearly 50 products and very large code base, which unfortunately
takes its toll on the number of issues that we have. I am happy to say
however, that the suite is getting more and more mature with each new release and we
are handling issues far better than before. We are dedicating more time for testing and training, without affecting the volume of work. Yes, there are areas we have to improve further and there is always more we can do to improve quality.
In case you guys have any suggestions on what we can do to make you happier, please feel free to share them.
Finally, erwin, please send me a list of issues which need our immediate attention in your opinion so that we can address them as soon as possible.
WinForms Unit Manager
the Telerik team
Check out Telerik Trainer
, the state of the art learning tool for Telerik products.