Thread

The EE 2.1.5 Beta has been released. This will be the final beta version before all functionality is rolled into ExpressionEngine 2.2 in June, which will become the new stable version and mark the beginning of our brand new release schedule, quality assurance guidelines (aka, how bugs are handled in a way you can count on), along with a host of other changes here at EllisLab that are geared to make EE the rock solid choice you need it be. We’ve been listening carefully these past five months and we’re excited about bringing changes you’ve asked for very soon. We’ll be writing about these changes between this release and EE 2.2! Now, let’s talk about 2.1.5 and what it brings.

The most significant change in this release is the move to storing file information (metadata, NOT the file) in the database. The release also includes over 50 bug fixes, the removal of the Blogger API module, as well as the addition of some feature requests. During the update process, you’ll see a link for an optional survey to help us identify the core strengths and weaknesses of ExpressionEngine as it is right now. It is completely option, but we’d appreciate it if you could fill it out.

As with the prior beta, this release should not be used on mission critical sites and you do so at your own risk. Please consider using the beta on development sites, personal sites, and sites that are easily rolled back to the stable version should an undiscovered issue prevent you from using the beta version.

Download here and read the change log (Build announcement) for a full description of the new additions.  And be sure to read the version notes, as files will need to be manually synced in order to be recorded in the database.

Keep reading for more details on this release…

Is 2.1.4 out of Beta?

Guy

Is 2.1.4 out of Beta?

Guy

2.1.5 beta replaces 2.1.4 beta. The stable release remains 2.1.3 until 2.2 comes out in June. With the release of 2.2 we’re going to stop betas altogether in favor of an easier to understand system. We’ll be writing more about that between now and 2.2’s release.

No- we went from 2.1.4 Beta to 2.1.5 Beta.  To be clear- this is the last beta release- the next release will see us go back to stable 2.2 - which will be in June.

We wanted one more release in beta to give the significant changes in file handling a chance to shake out and give them wider exposure.

ETA- Les is too fast!

Will stable mean no know bugs in the release?

I’m not quite sure I understand the “big move to the database approach to files” piece. Will there still be an option to have templates on the filesystem? Can we choose to keep images on the filesystem? What’s the advantage to storing things in the database?

@ Gavin - That was my big question. What is being saved in the database that wasn’t already? Surely you’re not putting the actual files in the db. Why is moving to the database approach to files important?

With the release of 2.2 we’re going to stop betas altogether in favor of an easier to understand system. We’ll be writing more about that between now and 2.2’s release.

To be clear- this is the last beta release- the next release will see us go back to stable 2.2 - which will be in June.

I’m glad to hear that you’re moving away from the betas. I thought they’d be a good idea at first, but I only think they’re a good idea if they’re quickly followed up with a non-beta version that takes into account the beta feedback.

As it stands, I know a lot of people who won’t even go near a beta due to the disclaimer you put on them, so these people won’t have had a stable version of EE for nearly 5 months. [edit: 6 months by the time of 2.2]

Personally, I found EE 2.1.4 Beta to be fine though. I’m keen to give 2.1.5 Beta a go, but am hearing about issues with some third party addons so I’ll have to keep an eye on that before taking the plunge.

Anyway, I look forward to finding out more about your new release cycles and hope this leads to more regular stable releases.

Thanks,

Stephen

Will stable mean no know bugs in the release?

That’s unlikely- but here’s our current approach.  Bug squashing is highest priority.  Each dev is responsible for resolving a set number (chosen based on priority)- the minimum goal being 48 bugs by code freeze- with no new bugs introduced.  Plus another 8 or so documentation bugs that were in there by my last count.  That’s the minimum acceptable and we expect to do significantly better.  However, we’re working on some features that I consider ‘must have’ for the file manager as well as some core enhancements.  So while bugs are a top priority, they aren’t the only commitment we have.

big move to the database approach to files

There are a number of advantages- most having to do w/searching/sorting once we have the ability to add more metadata.  With large directories, something as simple as paginating through them became clunky.  That would have been enough right there. 

That said- moving files into the db was a necessary step in bringing gallery functionality back to EE.  The long term goal is for files to be able to emulate the 1.x gallery functionality- only better.  And to be clear- it’s only the metadata that’s stored in the db, not the files themselves.

Right now, the metadata is not particularly sexy- as you can’t add/edit it yourself.  It’s basically filename and some file size/date info.  However, in the final iteration, there will be an interface for adding categories, titles, field data, etc.- anything that existed in the 1.x gallery.

And once all of that is in place- it will be an easy matter for us to import those old galleries into the new file manager.

Hope that helps clarify.  I realize that a lot of the coolest abilities just aren’t in place yet- but this was the big step that was necessary for them to happen.

@ Robin Sowell — Thanks for clearing up the files-in-db stuff!

Will stable mean no know bugs in the release?

Hopefully that will be the case. The big change in terms of our approach to bugs/Quality is that we’ll have public guidelines about how bugs are handled and what to expect when critical/major bugs are identified and verified. You’ll be able to point clients to the docs and say “I reported this bug, its confirmed, here is what they do about and when a fix will be released.”

Providing that transparency has a way to reduce client risk is our initial goal with the new approach. The second goal is a significant reduction in bugs and then a consistent burn down of them over time.

As it stands, I know a lot of people who won’t even go near a beta due to the disclaimer you put on them, so these people won’t have had a stable version of EE for nearly 5 months. [edit: 6 months by the time of 2.2]

1 month. EE 2.1.3 received a significant stability update last month based on progress on the beta. The version number was progressed but the build was.

But its that confusion that is leading us to change our approach.

Starting with EE 2.2 there will be a stable branch and a “tip” which is more like a “nightly build” or a developer build than a beta. We’ll have more detail about how that works prior to EE 2.2’s release.

As it stands, I know a lot of people who won’t even go near a beta due to the disclaimer you put on them, so these people won’t have had a stable version of EE for nearly 5 months. [edit: 6 months by the time of 2.2]

1 month. EE 2.1.3 received a significant stability update last month based on progress on the beta. The version number was progressed but the build was.

You’ve got me there Leslie! I wasn’t confused, I just forgot about the last stable release of EE 2.1.3 as I went with the new 2.1.4 beta instead. I’d argue it was nearly 4 months before that though, but now I’m splitting hairs… 😉

Starting with EE 2.2 there will be a stable branch and a “tip” which is more like a “nightly build” or a developer build than a beta. We’ll have more detail about how that works prior to EE 2.2’s release.

If this leads to more regular stable ‘tip’ releases (which I think is really important), as well as keeping developers happy with the more frequent developer builds (which in turn help clean up the next stable release), then I think everyone will be happy! 😊

If this leads to more regular stable ‘tip’ releases (which I think is really important), as well as keeping developers happy with the more frequent developer builds (which in turn help clean up the next stable release), then I think everyone will be happy! 😊

If the plan works we’ll have a new stable point release roughly every 8 weeks starting with EE 2.2. So once 2.2 is released the goal would be to deliver 2.3 within 8-10 weeks, 2.4 within 8-10 weeks of 2.3, etc… Shorter, consistent release cycles only doing build updates to address security issues and show-stopping bugs.

Meanwhile the “tip” is most likely going to be an untested/unsupported playground for devs and the brave that will give us a testing ground for new features, ideas, etc… as we build them. The primary goal of the tip release is to get feedback from EE devs and power users.

If the plan works we’ll have a new stable point release roughly every 8 weeks starting with EE 2.2. So once 2.2 is released the goal would be to deliver 2.3 within 8-10 weeks, 2.4 within 8-10 weeks of 2.3, etc… Shorter, consistent release cycles only doing build updates to address security issues and show-stopping bugs.

Meanwhile the “tip” is most likely going to be an untested/unsupported playground for devs and the brave that will give us a testing ground for new features, ideas, etc… as we build them. The primary goal of the tip release is to get feedback from EE devs and power users.

Sounds good Leslie, thanks.

<gets fingers out to start counting> So that means we can expect ExpressionEngine 3 by October 2012! 😉