How many Kentico CMS releases would you like to receive per year?

Now this is interesting. I was looking for an ASP.NET solution to a client’s web store that I work on. Usually all the best CMS solutions work using PHP so this could be something very worthwhile.

Updated version Import/Export function includes: Possibility to disable export/import of tasks on a global level.

New version includes Possibility of customizing alias path and language parameters using keys in web.config.

What difference does it make? If a dev shop can't dedicate resources to do the upgrade, they can just wait until the next release. At the least they could start new projects on the updated release. We do this all the time. We have v4.0, v4.1 and now v5.0 in various stages of our pipeline (dev and production).

You should release whenever you can: hotfix, minor or major - weekly, monthly or yearly. What am I missing here?

I appreciate the hotfixes, as they can be a lifesaver for certain problems that would otherwise have to wait months for a solution, which, I believe, is the point of releasing them.

I like what you've done with 4.1, 5.0. Releasing a minor upgrade to 4.0 was nice because some of the bigger features you had in the works could be released to us months earlier than the next major release. It also allowed all the 4.0 hotfixes to be tested and released together... sort of a "checkpoint" in the release cycle.

For anyone concerned about having to apply multiple hotfix packages during a development cycle, I would suggest establishing a phase in development where the current hotfix package is applied (a simple process) and then locked down. They're not usually imperative unless a specific fix applies to your site, and if it does, then it's worth it to spend the 10 minutes patching it, no? Certainly less time than running around in circles looking for a problem that Kentico has already taken care of.

I agree with some of the above posters that automatic upgrades would be a huge leap forward for the system. I realize the complexity is huge in such a request. It would take a move away from the "customize whatever file you want" approach and more into a "this is your playground area with supported hooks into the system that we'll never touch" such as a wordpress-style installation. The provider model is a huge effort toward this, and its a significant feature that I appreciate in the system. But that's for another forum...

Anyway, thanks for your continued effort to work with your partners to meet their needs!

Martin, I really appreciate the work that your staff does and the product you have brought forward. I would respectfully suggest though that to have a release come out and then have 4 or five hotfixes come out with a month of its release does not seem acceptable for an application that costs as much as yours currently does.
Perhaps there is some confusion in your comment on what was meant by my comment on integrating the hotfix in to the release. The best explanation I can give is that of when I use an open source application, when I download the package it usually contains all of the patches up to the date I downloaded it. This is what I am talking about. The very best open source applications have an easy upgrade path to incorporate bugfixes in minor release versions.(ex 5.0, 5.1, 5.12, etc).
From my own bottom line perspective, every hotfix costs time the company has to pay our techs for. Going in to a project we have no idea how many hotfixes we may have to apply before it is finished. Our minimum dev time on large projects so far has been 90 days - this recently has spanned some 20 hotfixes. We ended up doing them in four or five increments, not each one seperately, but it is still a time cost we have to eat.
If we have several projects going in tandem this really adds up and for a small shop like ours can get us in trouble on milestones.
I won't pretend to be an expert on enterprise level development, I can only share with you this effect on my bottom line. We have made a commitment to your product, which we believe in - we think it is something we can grow with. We also believe what we have been told in terms of improvements you are working on. You have always been responsive to customer and partner feedback and we appreciate that. Please feel free to take my comments with a grain of salt. I by no means intend to tell you how to run your business.

Les and Michael,

The hotfixes are not and cannot be (for obvious time reasons) fully tested on all configuration, that is why we cannot just put them to the main installation on-the-fly. Testing the release is a long way run for at least 1 month (if there are only small bugfix changes). What we can do is to re-release the version in the half of a year if we issue one version per year, and include the fixes to it, but since the hotfixes are cumulative, that won't really save you time if there is another hotfix next week. We will certainly improve the hotfixing and upgrading process in future, just let us know any specific issues you need to face currently with you apps while upgrading / hotfixing.

I would like to see one major release a year for the core functions. Individual releases for new feature packs (maybe new page templates. web parts and doc types for new functionality that doesn't affect core functions). An example of this would be if you made a new section of the site that handles something like adds a resume to a users profile in the community modules, you could just make the files associated with that new feature available for an optional install, no big upgrade necessary to get that feature.

I agree about integrating the hotfixes into the release package. It would help simplify/speed up Kentico installation significantly.

I think one a year is plenty. I think it would be good also it the hotfixes were intergrated into the release package, so that in implementation you do not have to patch each new installation as well as all the standing installations.

I completly agree with Ralph, and the upgrade to the new release can be a single annual fee also for our custumers ...

I think it's more up to you, based on your roadmap.

Foor us the upgrade procedure is way too complex to do multiple major upgrades. For the 5.0 upgrade we wrote down the step-by-step plan, there's 42 steps involved across 3 servers!

Hopefully you have a feature for automatic upgrades through the CMS interface on your roadmap as well.

One release per year is plenty. The amount if time it takes to test and then train the end users would make a more frequent schedule difficult.

I would like to see hot fixes for older versions as well.

I agree that one release per year is enough. The product is already very powerful and there are almost no features that I immediately need to have.

Upgrading 10 and more sites comes with a significant cost of time to properly do the job and making sure all functions work properly. So one release per year would be enough for me....