Archive
Monthly
Go
|
|
DNN Blog
Jul
23
Posted by:
Joe Brinkman
7/23/2010 4:58 PM
 Last year at OpenForce Connections in Las Vegas, Shaun Walker announced an updated release policy. The goal in 2010 was to move to a monthly maintenance release schedule along with Quarterly major releases. Prior to this policy announcement, releases were quite sporadic which made it difficult for our internal planning purposes, and also made it difficult for our users to schedule their own upgrade testing and deployment. When we first committed to this new release schedule, we knew that it was going to take a little time before we could get into the groove with the new release cycle. By February we had 3 monthly releases under our belts and things looked to be going pretty well, so much so that I blogged about it.
We are now 8 months into the release schedule and following some issues with a few of our recent releases we’ve had a lot of feedback from customers and community members regarding the release schedule. Some users have indicated that monthly releases just didn’t give them time to properly test and upgrade their sites before a new release was coming out and they had to start the cycle all over again. Other users worried that committing to monthly releases was hurting the quality of our releases. Conversely, some users liked the frequent releases because it meant they could get bug fixes quicker. Some users also liked the predictability of the release schedule.
After a lot of discussions with community members, with the core team members, with customers and with partners we have decided to modify our release schedule to address many of these concerns. Starting with the 5.5 release we are moving to maintenance releases every two months and reducing our major releases to 2 or 3 a year depending on the complexity of the features included with each release. We will still be targeting specific release dates so that we can scope each release and set proper code-freeze dates, but we will adopt a more quality driven approach to the final release date. If we need an extra week or two on a release to make sure we get it right then we will extend the release date to make sure we meet both our own quality standards as well as yours.
We believe that these changes to the release schedule will allow us to still provide a level of predictability in our releases while also addressing the pacing and quality issues raised by many of you. We appreciate the feedback that has been provided on this and many other issues and are always willing to listen to your concerns. As I stated in a recent blog post, Open Source works best when you get involved. Your feedback does make a difference.
4 comment(s) so far...
Re: Your Feedback Can Make a Difference
I'm not sure I understand the argument about not having enough time to test monthly version releases. No one mandated that you have to update your DNN installation everytime a new one is released. If the version releases are too close together for you, then upgrade every other month, or every quarter or whatever schedule you can manage. Furthermore, the old addage about "don't fix it if it ain't broke" applies. If an older version works just fine for you, there may be no need to upgrade at all.
Also, there are often very important specific fixes or enhancements that people are waiting for. There is no reason to make everyone else wait just because some people need more time to test a release.
By Jay Mathis on
7/24/2010 2:06 PM
|
Re: Your Feedback Can Make a Difference
Joe,
I believe that the revised process is for the better. However, one thing would really help in my scheduling site upgrades .... keep the Release Schedule updated at all times.
It might even be better to revamp this schedule to include a short description of each upgrade in the pipeline. This would give me a better idea of which release I plan for. The current release schedule available on this website is rather sparse, with no real up-to-date information or data.
By Hans Zassenahaus on
7/24/2010 2:06 PM
|
Re: Your Feedback Can Make a Difference
@Jay - While I agree with you about site upgrades, it is not my place to determine how a business chooses to run their own website. If making this change aids some of our customers and provides greater confidence in the platform, then that is a good thing. While we cannot always accomodate every request from users, this is one area where we can. There are some good reasons internally for making this change as well. It will help minimize some of the overhead associated with making a release and allow us to focus that energy on some extra time for fixing bugs. Definitely a net positive.
By Joe Brinkman on
7/24/2010 2:09 PM
|
Re: Your Feedback Can Make a Difference
@Hans - We are looking at how we can better communicate the roadmap. One of our primary concerns is not setting false expectations with our users. Right now our roadmap seems to be a little more fluid than we are comfortable publishing. Since we have shifted to scrum, it means that from sprint to sprint we may readjust our priorities based on market feedback, changing competitive landscape and our own developers abilities to meet their own estimates. As we get a little more time with scrum under our belts, the predictability is improving, but it is still not quite where we would like it.
By Joe Brinkman on
7/24/2010 2:13 PM
|
|