With yesterday’s M4 release all wrapped up, this is the perfect time to ‘talk shop’ about the releases in general and some of the comments we are seeing.
What are the M’s for?
The M-releases are our best effort to provide an actual ‘release cycle’ for ourselves and users alike. In previous generations of CM, we were super active but released sparingly, with months between releases and with an unpredictable cycle. This was bad for users, specifically those less likely to use nightlies, and bad for developers on our team – never knowing in advance when we’d collectively say “Okay, let’s do a release now”.
M-releases exist on a monthly cycle to force our hand at not only releasing, but addressing bug-fixes in a timely manner. These releases are scheduled for the first week of every month, usually the first Friday/Saturday. Every M release for CM 11 has gone through a very specific code preparation and release process, both of which were less stringent in CM’s previous incarnations. In terms of time, this allows for roughly 3.5 weeks out of any given month for code review and mergers to be included in a release. The last week or so is spent making sure that the code for release is tested and branched accordingly to the new ‘stable/cm-11.0′ branches on our Github (example). This ensures that newer, more experimental features are properly vetted in a separate release stream, and do not impede or prevent a timely release.
What M-releases are not
When we introduced the M’s, the common consensus was that they were just specially named nightlies. This was close to true for the majority of the CM9 cycle and most of the CM 10.x cycle. With CM 11 though, this is no longer the case. CM 11 M# releases are a code path that lags behind nightlies.
This means a few things:
- Nightlies have newer code than the M-releases
- You should be extra careful flashing an M build on top of a new nightly due to #1
As the Ghostbusters would say, “Don’t cross the streams”. While this isn’t a hard-stop rule, it is still very apt advice to take into account. Let’s give you a real-world scenario.
M4 was branched for release last week – let’s use an easy date and say February 28th. This means all the code that exists in the stable/cm-11.0 branches on Github contain code 8 days old, with only bugfixes placed on top (or unstable features removed). This also means that any change merged in the last 8 days to the master ‘cm-11.0′ branch is not captured in the branch for M4. On March 2nd, we merged in some relatively sweeping telephony changes based on QCRIL (Qualcomm specific radio code) and the beginnings of Multi-SIM phone support. If you are using a nightly from March 2nd to today, you have this new code. If you flashed M4, you don’t. Simple enough right?
But what happens if you are on nightly March 7, for example, and then flash M4? In terms of code, you have just downgraded. Downgrading can be perfectly benign, or flat out make your phone unbootable. In the QCRIL example, if you downgraded you would see broken phone calls and radio behavior. This is one of the many reasons veteran users advocate making a backup before making any changes, and we’d echo that advice.
So what are the release streams?
There are effectively 3 release streams for CM: Nightlies, M/Stable, and Installer:
Nightlies are always the most bleeding edge in code, features, and yes, bugs (including the kind that may prevent the device from booting at all).
Update process: Flash a new nightly on top of the old – no need to wipe
M/Stable are specifically tagged, branched, tested and released. If you are a tinkerer but adverse to the chaos of nightlies, this is for you.
Update process: Flash a new M/Stable on top of the previous M/Stable – no need to wipe
Installer builds are those served via the CM Installer applications (Windows, Mac). These builds are specially signed and named separately – there is no concept of an ‘M’ build for this release channel – so saying ‘Installer skipped M#’ is an incorrect interpretation. This channel only ever receives specially created Stable builds – they even come with their own naming structure (eg XNPQ02R).
Update process: Incremental OTA’s are provided using the CMFota application – updates are handled by device logic with minimal user interaction, no wipe needed
If you are a nightly user, use nightlies. If you prefer to tinker but want something less chaotic, use the M/Stables. If you aren’t a tinkerer and don’t want chaos, use the Installer builds (if available).
If you want to cross streams, make a backup first! It should also be noted, to cross into or out of the Installer build release channel will require you to wipe your data (due to the different key signing).
Devices and greenlights
As a team, we leave it to the maintainers to opt-in to releases. If for any reason your maintainer does not flag a device as ready for release – be it for technical reasons, lack of time, or anything else – we will not issue a release for that device.
For some examples, I’ll point you to the d2lte, jflte and hlte devices. These are the unified builds we announced last month. The maintainers decided that the unified devices were not ready to be issued outside of the nightly release stream and so no builds for these devices were generated.
Part of what I do on this project is the user interaction – talking to you all via this blog, comments, forums, social media, etc. All too often I see “you didn’t release for [device], you must have abandoned it”. This simply is not the case. You trust the CM maintainers to keep your devices functional and in a working state, if you didn’t you wouldn’t be using the work that they provide. But part of that trust also entails trusting their decision making abilities about the suitability of any device for release. These guys are working hard to get your devices in the best possible shape – so when they say “no” to any particular release, don’t take it as a slight against you, they are making a judgement call.
We all know that everyone wants the latest and greatest, but that mentality is for the nightly channel, and if the latest and greatest is what you want, use those. But for M/Stable, you want things that work (for those that will inevitably point out various bugs on M4 now, please do so constructively via JIRA).