Shared publicly  - 
 
CyanogenMod Build Tags

We recently introduced some changes in our naming conventions, such as deprecating '-kang' in favor of -unofficial. We thought it would be beneficial to explain the names, and how they fit into our development.
Edit: Added some clarification about the new tags.

Alpha: These are very early builds, and considered experimental. These builds often have hardware partially working or outright non-functional. These are considered unstable and not-recommended for daily usage. Bug reports are not accepted.

Beta: This phase immediately follows the alpha phase. These builds are usually hardware complete (all or most hardware components are functional) but still have outstanding bugs, known or otherwise. These are considered stable, but not recommended for daily use unless you are an experienced user. Bug reports are not accepted.

Release Candidate (RC): Release candidates exist as publicly recommendable betas. The majority of known bugs are addressed, and aside from finding any other critical issues, the code reflects the code that will become the 'stable' build. These are recommended as suitable for daily use, and bug reports are accepted to our issue tracker.

Stable: These builds reflect what we believe is suitable for every user in our community. They have passed the 'wife' test, the all important phase where you would feel comfortable placing the OS on a loved one's device. Bug reports are accepted to our issue tracker, and the cycle begins again.

Now, there are three other tags that need to be addressed. As we are still in the process of discussing how to automate the new build servers, these may change, especially if we change the automation schedule from daily to something else ("_nightly_" wouldn't make much sense in that case)

Nightly: These builds exist outside of our release cycle, and run in parallel. These builds are considered highly experimental, and carry the mentality of "if it builds, ship it". We do not monitor the issues in nightlies, they are merely 'bot' built checks to see if code compiles. These builds, are community reproduceable, meaning anyone in the community can take the same instance of code, and build from source.

Unofficial: This tag reflects that the build was not released as part of the CM 'organization'. It supersedes any other tags present on the release. Unofficial builds should be considered just that, and not reported to our issue tracker.

Snapshot: The latest tag in our arsenal. This tag reflects builds that are not 'in-line' with current source. This means, these builds may have additional patches not yet merged into CM mainline, or code not yet on gerrit. They are 'non-reproduceable', meaning, you as a community member may not be able to build this exact set of code. These builds will be used more often in the near future to reflect items we need tested by the community, prior to their incorporation.
156
22
Robin Muresan's profile photoLucas Farré's profile photoDan Paul Nguyen's profile photoDan Broderick's profile photo
95 comments
 
would love cm7 on my evo 4g, but it has HBOOT 2.18, can't get around it
 
+Jeremie Long Your point is valid, but this is really no change from our current practices. The reasoning is the builds accepted against the tracker are specific builds that have been tested by the various maintainers prior to release and given the subsequent 'ok'. This is also so that maintenance of the bug tracker is reasonable.

You are right, your download of the code and ours should be exactly the same, this is just our preference.
 
Usually "Snapshot" refers to a point-in-time build directly from source. If it were up to me, I'd use another term to describe builds that include patches and/or uncommitted code.
 
This is great. I was always a little confused on what a snapshot was.

Looking foward to Hourly builds! :P
 
I'm looking forward to the day when servers are powerful enough to do on-demand builds. An as-of-this-moment build of whatever the source looked like the moment it was requested. Granted that'll be a while yet, but it sure would be neat.
 
Doing the compile client-side is cakewalk, as you pointed out. Id love to see it on the server: I download a compiled version that was just created on the fly for me. This would take heaping shit-tons of cpu and ram on the server though, and probably will be relegated to the "computational unfeasable" pile for a good couple years.
 
+Dan Bowkley +Jeremie Long it is certainly not infeasible or impractical - all it takes is a relatively small Amazon EC2 build automation. It'll cost some money, for sure, but probably less than you imagine. Would you pay a few bucks for a "custom" build made for you on-order? That'd leave some profit as funding for the rest of the project.
 
Jeremie Long: why settle for small instance? Try this for $1.8 per hour.

High-Memory Quadruple Extra Large Instance

68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge
 
+CyanogenMod: I also agree with +Mark Lewis that snapshot is not very good name for the purpose you mentioned. If its main purpose is to introduce some new feature or change and collect user feedback then better name would be a feature build than snapshot build.
 
Quote:
these may change, especially if we change the automation schedule from daily to something else (nightly wouldn't make much sense in that case)
It's always nighttime somewhere on Earth! ;)
 
+Travis Rubio for Sensation head over to xda developers site and get the OpenSensation CM9 rom by Vorbeth. Im using it and I love it.
 
but with gerrit and the state of cm9 now most of the updates are no features and minor bugs so a nightly for most devices doesnt make sense, for new devices with rapid development a nightly should be used but after that honeymoon period a 2 or 3 day build would be fine unless a critical bug is fixed, which is not likly to happen due to gerrit
 
Lmao the "wife" test. I know exactly what that means
 
+Jeremie Long This next sentence can be taken as sarcasm, so I want to make sure you understand that I am being sincere when I say it.

Thank you for calling us out on our flaws.

I truly mean that. We are in the middle of the process of transitioning from a hobbyist group to something more official and greater than us as individuals. This isn't without growing pains, which you have been right to point out. The feeling you get, about us being "petty", isn't out of some selfish purpose, its out of our inexperience in this area.

We aren't mature enough to know how to handle self-builds against our releases on the issue tracker. But that doesn't mean we won't look at ways to make that work. And I don't believe this makes us wonder from the open-source aspects of the software. The tag may be inaccurate for its use case, that can be changed. But as you can imagine, there is a need to be able to separate 'official' from the rest. This is just the measure we have in place for now.
 
+Manas Tungare touche :) The phrase is a hold-over from the older days of CM, where Steve's wife would give the blessing.
 
+Marcin Jaworski +Mark Lewis agreed, it may not be the most clear naming scheme, and isn't permanent. We may very well transition to adding an 'Experimental' tag in its place.
 
+Jeremie Long I wrote "relatively small automation", but if you want to pull "small instance" out of thin air, that's your prerogative.
 
I always knew what kang meant but never could figure out the word for it. Unofficial works. I am under the impression that an unofficial build is any build not done on CM server, and unofficial is a good way of saying that. I.E. AOKP is an unofficial (port) build of CM9. I know that it uses CM9 code base and is potentially modified from there.
Snapshot to me sounds like, to use my previous example, AOKP DEV made one dip into the repo for CM9 (say 3/14/12) then has used that base since. This is a ROM which is not source synced on a regular basis. I think I like Experimental for this purpose.
 
But likewise, does it make your build 'official' should you start distributing it?

Maybe -Derivative or -Source is a better tag, but would you disagree that a line should be drawn to differentiate them?
 
+Jeremie Long I see your point but at the same time if its not from a CM server its not officially a CM build. Whether you modified it or not is unknown to anyone else. Example: I download and build cm9 for sgs2 and post it somewhere, people don't know if i did anything or not to the code. I could have put in all kinds of stuff then called it official.
Also another term to use is "port" for an unofficial build, but that would be more for devices not already supported by CM team.
 
+Andrew Lieffring If I pull source, modify, make then post it to XDA, I can put what ever md5 my file has. I believe you said that with the half. So yes you could compare two instances (official and unofficial build for the same device) with md5 but any change in the file results in a change of the hash. And if i posted a build I would post my md5 so that people know the download worked correctly.
 
It sounds like it's more a question of whether users should trust the build, like whether it's Signed or Unsigned. You don't want people claiming that potentially malicious "unofficial" builds are CM. That would harm users and damage the project's reputation.

Still, it seems like there should be a way to reproduce exactly what the CM team released and not have it treated as a lesser build.
 
Fair enough. -Source does make more sense for the purpose. As for you syncing the stable branch, that's reliant on us tagging them appropriately and clearly (eg gingerbread-release versus gb-7.2). I'll run this by +Ricardo Cerqueira and the others.

My question is, how do we handle the " to your liking" part, if that modification introduced bugs that weren't in 'official'?;
 
I don't agree. Building a package to your liking does make it unofficial. As Official means it was built to the CM teams liking. The only case I can see where you could argue is one where you pulled the source, did nothing to it and built it.
In my opinion (and it's just like that, since I'm not part of the CM team) CM has the right to protect their project, and reputation by only allowing a build from the CM server to be Official.
 
+Jeremie Long i find the unofficial tag fair, as its a marker that represents it is not sanctioned by cyanogenmod. it didnt come from them, so why would it be in the bug tracker? lets say u built the source and so did cyanogenmod's build server at the same time.. yes they will be identical, but they will be different because u built it.. u could of done anything to it since u built it.. and even in the case as i said that both was built at the same time, the build.prop will be different because it says who built it and on what computer.

all im saying is that unofficial tag makes sense because u built it.. if u built from aosp for toro, would that make it an official update for it?
 
+Jeremie Long If anyone can produce an official build from source, how do you propose that a modified build be distinguished from an unmodified one? The unmodified one will match the Official build that CM releases. The modified one won't (and could include malicious code), so there should be a distinction.
 
+Jeremie Long i do use open source packages, all the time, in fact i use linux as my main os.. but there is a rather large difference between that and android.. android community has tried such an approach before, and people have abused it.. thats the whole reason the kang tag even started..

i myself distribute an unofficial cm9 nightly rom every day, if i were to drop the unofficial part it would mean that i was part of cyanogenmod, but im not.. thats the difference, u r not part of the team, u can throw whatever u want into the build, and thats why its unofficial..

EDIT: i build for toro btw
 
+Jeremie Long in that view there is no difference, but theres a flaw in this.. it is human as it tends to be.. it matters upon the skill of the builder, if he actually put it together right.. lets say someone built cm9 and forgot to put in a certain prop file and distributes it as official.. then everyone who downloads it will either go to the dev and/or cyanogenmod complaining how theyre camera doesnt work or something.. hell, u could even put in the wrong commands and built it in a way that it couldnt even boot...

this whole thing is an os, many things can go wrong in building, and do u ever see any organization who built ubuntu claim it was official ubuntu? if they were exactly the same i guess u could claim it as official but then seeing how there is no way to check that during building..
 
+Jeremie Long I think people who are building CM from source can also check an MD5 and assure themselves that it matches an "Official" build. These tags are not for power users, though. They are for users who acquire CM through distribution channels so they know where the build came from.
 
+Jeremie Long I do. I even said as much in the comments above. However, it potentially compromises the brand and the integrity of their support system, and you've offered no concrete workarounds. "Then don't accept bugs like that" doesn't fly.
 
how are we not able to build what they are releasing? my builds r exactly the same as the ones they build, but does that give me the right to say its official? no it does not sir, and thats where i stand..
 
I think a simple lil "SHUT THE FUCK UP AND GIMME MY ORDER" should alert the bartender that you're more then just a random passerby. :)
 
+Jeremie Long I'm not either. If we're asking them to change something, it is our job to make a case for the change.

If they renamed Unofficial to ThirdPartyBuild, would that satisfy you?
Edit: Could also be Source or BuiltFromSource, though those would arguably apply to any build.
 
+Jeremie Long congratulations, u suck at reading.. i build for toro.. toro... thats the vzw galaxy nexus i suck at typing i forgot to mention what i build for x.x
 
+Jeremie Long I agree that Unofficial is not a good label for something built from unmodified source.
 
+Jeremie Long But now it's a question of whether the CM team is willing to support builds they didn't make and distribute themselves. If you want to report a bug, due diligence says you should make sure the bug exists in their build. They can't necessarily trust your build.

Edit: ...because there's no way to know whether you made modifications.
 
+Jeremie Long its not the code thats being labeled, its the build.. i built it, not them.. if u built it, its ur responsibility.. why should cyanogenmod support what u make? u sound as if u dont want to take responsibility for what u make
 
The root of this matter is support. No open source project is obligated to provide any support at all. However the Cyanogenmod crew has offered to provide a certain amount of support. Their resources (and likely patience) are limited so they have provided us with a handy list of builds and circumstances where they are willing to help.

What that means is that if you build your own copy, you're on your own. The last thing they need is to troubleshoot your build environment on top of their source. The labels are meaningless, whether -unofficial, -source or -stfuyoubuiltityoufixit, the outcome is the same.
 
Also to address an earlier post. If you make a application from source, I would not expect you to post it as an official .deb for others to install. Yes, if you DL'd the source and built it your self, sure it is official on your box, but I (personally) would not call it an official build for release.
This is to say, if you download the source for firefox and build it on your machine, you should not then turn around and post it for others to use as "official". I've been around open source for a while, I won't say I've developed, but I have build things from source and written some.
I don't care if Larry Page or Linus Torvalds built it, if they are not on the CM team and if they don't have the ability to sign it, then it's not official.
Also I realize that where it is build doesn't make it official. When I said CM server, it was a simple way of describing the fact that it was build by a member of the CM team who could then be considered official. It may or may not be built on Steve Klondiks Server, but it does have his name on it.
Official AOSP would only come from Google. If you built it from source on your machine it is AOSP but it is not official. I don't need to have been doing open source for very long to understand that.
 
+Jeremie Long im not part of the team, its open source code.. u can do whatever u want just as long as u dont say its official from cyanogenmod.. im sure anyone else will say the same
 
+Jeremie Long nope, the only thing I mentioned was about support. If you want to build your own ROM from source you're welcome to. If you want support for that then you're out of luck.
 
+Jeremie Long Well that is a fair point. I assumed that the terminology describe here was with the purpose of distribution and not necessarily bug reports. The point was made that it would be difficult for the CM team to open bug reports to builds that they did not create due to the fact that they would not be able to verify the builds integrity. But I do understand how it would be annoying to not be able to submit a bug if all you did was, say, take out a language pack.
 
If you want to fork it, rebrand it and support it, knock yourself out. It's open source after all.

The maintainers owe you one thing and one thing only: a copy of the source. Anything they want to provide beyond that is entirely up to their discretion and the goodness of their hearts.
 
+Jeremie Long just remember, cyanogenmod itself is just a fork from AOSP.. albeit a heavily modified one
 
+Jeremie Long it is like voiding warranty. As soon as you are running a build that is not compiled by +CyanogenMod there is no proof / guarantee that the code is not modified (even though you may have not) and therefore it is unofficial. If you are not going to be modifying code then why can't you just download build and use it in the first place?
 
I agree +Jeremie Long that trust can be an issue but if you don't trust +CyanogenMod then logically you should be reading each line of code and I am very positive that is not happening.
 
So you don't trust CM to compile clean code, but you want them to trust you that you didn't change anything? It's a two way street, pal.
 
Dang you guys are tech smart. Most of it went over my head! I just rooted, Odin and flash.
 
+Jeremie Long a build you do is unofficial because no one can verify that you haven't changed the code. If they let people report issues from their own builds how can they sort out who made their own changes and who didn't?
 
That's much easier said than done. Makes much more sense to keep bug reporting to builds they know all the variables of like build date, time, device, unmodified code, ect. Far too many possibilities for an organization with no employees to verify.
 
No. I'm finished ranting. You guys apparently don't appreciate open source and what it truly stands for.
 
+Jeremie Long by the way, my comment before the last one, and the last comment was honest.. cyanogenmod is getting rather large an organization.. power comes corruption.. some sort of check and balance needs to be built
 
I'm feel like my views are being neglected. The real reason behind them. Its much easier to set things straight now then when this machine is full force.
 
well put something together, some sort of mechanism...
 
Right, but apparently cm is set on their builds from their server being the control. Unless that changes it doesn't matter.
 
if nobody does it, it wont happen.. talk with the heads of cm or else the idea will perish... if u can somehow incorporate it in the build code, submit a gerrit
 
Is there any chance you guys can put the torrents for the nightlies in an RSS feed? It would be nice to get the builds and help distribute them when they come in.
 
Eagerly w8in for Cm roms for i9100G
 
hello, im chinese nexus one's user. i like cm mod .i want to ask, when will upgrade to the nexus one? thk U
 
i cant seem to find any cm9 for lg optimus x2,anyone know where i shall look?
 
+CyanogenMod If you change the nightly tag, how about untested or experimental? That would certainly make our point clear
 
+Jeremie Long I see where you are coming from, but that problem could apply to anything open-source. Google has an official release of Android 4.0.4, not just modified builds of Android 4.0.3. For open-source to work, there needs to be some closed-source too. Maybe a source tag would be good, but unofficial works for now. If something is built on their servers, it is called official because they know that there is no malicious code with it. Even someone calling their build source could have added malicious code to it. Which is why we have the system we currently have. There are problems, but less then the other systems.
 
I hear, and it makes sense. How about something along the lines of "Trusted Users" special class of users that cyanogenmod trusts to build from source and compare against "official" builds. These users would be appointed by +CyanogenMod for the sanity of both +CyanogenMod and its users. Even +CyanogenMod has said themselves they are trying to move to be more Official. I think there needs to some check and balance, "Trusted Users" could provide the needed feedback to create this.
 
+Jeremie Long to have what you describe these builders would have to be completely separate from Cyanogenmod and would have to build their own trust in the community. If they are appointed by Cyanogenmod then they are ipso facto members of Cyanogenmod and therefore not to be "trusted" to provide a clean build.
 
Well, yes they would. There could be lets say a point of reference on the cyanogenmod team, example, cyanogenmod source - mailing list, which would allow source builders to enquirer about differences in source builds and official builds, in a public, professional manner.
 
+CyanogenMod I was wording if you could come to my house and install your rom on my device. It's the least you could do after building all this for FREE.
 
That's more than most open source projects do. Don't think it's all that nessceary, either.
 
On incredible s unnofficial aokp they have solved the issues with netflix
 
Snapshot? That should be synonymous with nightly shouldn't it? Why not call it Feature or something to that effect? This convention could cause confusion.
 
Why does it take you so long to release an update for Xperia Arc???
 
I am still waiting for HTC sensation. Currently using virtuous no sense ics rom
Add a comment...