Unfortunately release cycles do not get enough attention so it seems. There are so many external factors that affect a company's release cycle, customer requests / demands, market forces, critical bugs, etc. It seems like timing is way down the list of motivators.
 
We use a 3rd party control set (the name will remain anonymous) and the parent company has not thoroughly considered what a release can do to the developers that use it. For example, they typically release 3 majors a year that contain some sort of bug fixes, new functionality and new controls. Typically they do not release fully regressed hot fixes during the interim but instead they release internal builds. These builds have not been through the full QA process so for a production site they are worthless. That leaves major releases as the only option for us poor developers.

I personally had found several buggy items in their 2nd release of the year so I had no choice but to try the 3rd release (remember no hot fixes). Well in the latest release they decided to change the appearance of the yes/no dialog to remove the no button and make it a link instead (there are plenty of other issues here as well but let’s focus on this one). I know it is not a major change but imagine if I had a 120 page training manual with screen shots or 50+ training videos (this is how we train/support) or a large help file full of the old style dialogs and now I have to go update all my supporting documentation. Maybe it was in the read me file and yes I am guilty of missing it, but the real issue here is their release schedule.

I have proposed what I consider a nice release schedule. One major release a year where all things are candidates for change. User interface paradigm shifts, colors, skins, etc. Then supplement the releases with minor releases that have been through the full QA process along with any hot fixes in the same process. Of course introducing new controls during the year is ok as long as existing controls are not broken. Then we could plan our upgrades appropriately without having to take a major release just because they broke something in the previous one.

Then the life lesson really hit home. One of our vertical markets is extremely busy during March, April and May. So any major UI paradigm shift needs to occur in fourth quarter so our user base will have time to adjust and train on the new components prior to their busy season. What it really means is we have to restrain ourselves as product managers and developers, scheduling the significant changes at the right time for our customers.