Why Maintenance Releases Matter

I'm cross-posting this from my blog on the Yocto Project web site. Please go there to learn more about embedded Linux and the work we're doing in the Yocto Project to make it easier for you to develop embedded devices.

As the calendar year winds down, I find myself tapping away at the keyboard at my sister's house in Denver, Colorado in a snowstorm. I just spent the morning digging out our rental car and shoveling my sister's driveway and her next-door neighbors. It is a time like this to reflect and, yes, to remember that one of the reasons I moved to Portland, Oregon was to escape the snow!

This has been a busy month in the Yocto Project, with all kinds of activity jumping along:

    • We launched a maintenance release 1.0, dubbing it Yocto Project v1.0.2. Our 1.0 release was last April, but we try to provide update support for at least a year after release. This release includes security patches as promised and some fixes to make sure the build works with more recent Linux distributions.

    • We're also working on a maintenance release for 1.1, which came out last October. Nobody should ever fear that compatability has been broken in a maintenance release. My mental rule of thumb after a few decades in the software game is that you should have no more than 10 - 12 bug fixes in a maintenance release, which also constrains the amount of QA you need to do. 1.1.1 though will have a few more changes in place because we want to address some issues raised by Matthew at FreeScale and to make sure that the release meets their needs. More on this later.

    • Our development, QA and release engineers also produced the first milestone from our 1.2 release, due this coming April. We produce these milestone releases every 6 weeks or so. Our idea is to constrain the length of time that the development window is open to make sure we can freeze, stabilize and run a full QA sweep. Then we provide these little milestone releases to you so that you can have some demonstratable features to use in a somewhat more stable form. At least, it should be more stable than developing on the Master branch! As I wrote this, we decided to go ahead and release the M1 milestone.

It may seem like we're putting an inordinate effort into producing these maintenance releases. In fact, we had hoped to have 1.1.1 out in December, but putting three releases out in one month was just too much for our release engine to handle.

Why make the effort to do maintenance releases? Here's the way I think about it:

    • The Yocto Project is an open source project, not a software product. So we're not supporting our releases for years and years. We're looking for our friends at Mentor Graphics, Montavista, Timesys, Wind River and others to produce software products which use Yocto as the upstream.

    • On the other hand, by providing these additional stable releases, it shows that we care about the developers who base their products on the Yocto Project. We know not every product development cycle perfectly aligns with the every six month Yocto Project cycle. Having these maintenance releases helps to support them.

    • As I mentioned, we try to keep these releases as stable as possible, just fixing critical bugs or security patches from upstream.

    • So we think these maintenance releases matter, to demonstrate that we care about you the developer who uses the Yocto Project to make the magic happen on your devices.

By the way, I'd like to offer a shout out to Joshua Lock, who has been spearheading the development side of these maintenance releases, Beth Flanagan for release engineering work, Jiajun and the project-wide QA team. And also to Paul Eggleton for reminding us to get the 1.0.2 maintenance release on the schedule.

Para obtener información más completa sobre las optimizaciones del compilador, consulte nuestro Aviso de optimización.