When I took over as CEO, two of my highest priorities were to change our internal development process so we could have a predictable release schedule and to improve the stability of our releases. We’ve seen definite improvement in both those areas this year, especially if you compare 2.1.x to 2.2.x. What follows is a summary of what we’ve learned so far and how we’re using that to improve.
At this point in time, we can do things internally as a company that we’ve never been successful at before. For example, we have the capability to set a release date and actually release it on that date. If you’re a long time fan of EE, you know this is brand new. We’ve banished the “cowboy-when-its-done” mentality in favor of hard internal release dates.
It’s been a rough transition, but well worth it. I’m sorry for the headaches you had to deal with while we made this transition, particularly between 2.2.0 and 2.2.2.
What we Learned
We were too aggressive with our release schedule and though we hit every internal target we set, it did not improve the stability at the rate we want. Specifically we’ve learned that we tend to work best on this schedule:
6-10 week internal development code freeze 1- 3 wks internal review, 3rd party dev preview
This leads to a schedule of roughly 12-14 weeks between releases vs. the 8-10 timeframe we originally implemented.
Though we were happy with our internal review of EE 2.3 in late August, we decided to make the switch to the longer schedule now, hence the new release date of 2011/10/11 (within a day either way).
We’re going to be watching 2.3’s release very carefully to see if the new process continues to show improvements like we want. If it does, we’ll expand this even more for EE 2.4, especially in terms of allowing 3rd party access ahead of time to help test and to make sure 3rd party devs have access to new releases ahead of time.
Next, we really wanted to simplify how updates work. We’ve taken two steps toward this. First, we eliminated paid 2.x updates completely. And second, starting with 2.3, we changed how the version numbering works and eliminated “build updates.” Here is a brief recap.
2.x - Any update that moves the platform forward with more than just stability improvements (aka, bug fixes). 2.x.x - Only bug fixes (stability improvements). No new features or improvements are introduced.
This means that with the new schedule, there is a release, a 2.x.x release 4-6 weeks later if necessary, and then a new 2.x release 12-14 weeks later.
Our goal is to make that predictably awesome.
Next, we learned that the way we tried to communicate this turned out to be pretty useless. Yes, we’re talking about the Forecast page.
Between now and EECI, we’re going to remove the current Forecast page. After EECI, we’ll bring it back as a reporting mechanism that is based off our internal reviews and updated at the end of every internal review (roughly every two weeks). Our goal is for that page to give you a more inside view of the ups and downs of development life instead of vague promises about future things that isn’t updated regularly. I suppose I should revise yesterday’s “todo” list with this.
What all this means is that EE 2.3 will be out on October 11 and EE 2.4 will be out roughly 14 weeks later, around January 17th. We have releases planned between 2.3 and 2.4 for add-ons (Discussion Forums for example).
What’s coming in 2.3
We’ve got new features coming in 2.3. They are customized Pagination for Channels/Comments, an improved member search feature that we think is pretty good, and a bunch of little things that will make people happy. We also have a refreshed User Guide that we’ll be launching at the same time.
If you want an inside look at the above, sign up for PixelBuzz, the EllisLab email newsletter here. Subscribers will get the first inside look at EE 2.3.
Everybody at EllisLab is monitoring these changes. We’re here to serve you and provide you what you need in order to be successful with ExpressionEngine (and everything else we offer). As always, if you see something you love, merely like, or hate, let us know.