-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Root CM 10.1 Nightlies Discussion
- Thread starter tdm
- Start date
-
- Tags
- lg spectrum
Well that is just it, I did that and all other options trying to "force" the issue and none of the update options showed the RC's at all. Well I may have seen them ONCE but that was it. My wife's phone got it though.
I have 010 RC2 on the phone because I DL'd it and did a clean install. Just want to know if there is a way for the phone to look forward and not back since I am on 010 now. Ya know?
Rich
I'm not sure how you're getting that the latest nightly is a step back. If 10.1RC2 came out today (for arguments sake) and you check for an update tomorrow... the latest 10.1 nightly has new code changes since 10.1RC2 came out... thus it's an update.
It should show the rc if you check the day it comes out....otherwise it's already superseded by the newest nightly
Also, RC's aren't stable builds. They're candidates for a stable build, so they won't show up as anything other than a beta, just like nightlies.
Sent from my VS920 4G using Tapatalk 2
If you chose Stable only, then Yoinx is correct, niether the RC's nor nightlies will show up. So you did try to select New versions (incl. Nigthlies) and they still did not show up?
You could try downloading the latest nightly and installing manually through CWM and see if that corrects the issue.
tdm
Android Expert
Just learned something today. rmcc said on an internal CM post "We've stated on a number of public posts that no wipes are necessary for CM updates. Ever. Part of our work is to ensure that." ... "Nightlies are fair game, releases aren't. "
In other words, upgrading from CM 10.0 to CM 10.1 should not require a wipe and it's a bug if it does. But if you have problems flashing nightlies, that's part of the fun...
I imagine that a corollary would be, reporting bugs on dirty flashes to nightlies is not welcome, but reporting bugs on dirty flashes to M releases and RCs should be welcome.
Also, before anyone asks, no, AOKP does not have any such policy and is not shy about asking users to wipe for upgrades.
In other words, upgrading from CM 10.0 to CM 10.1 should not require a wipe and it's a bug if it does. But if you have problems flashing nightlies, that's part of the fun...
I imagine that a corollary would be, reporting bugs on dirty flashes to nightlies is not welcome, but reporting bugs on dirty flashes to M releases and RCs should be welcome.
Also, before anyone asks, no, AOKP does not have any such policy and is not shy about asking users to wipe for upgrades.
Yeah... I tried all of the options. The ink only reason that I am on cm10.1.0-RC2, is due to downloading it and installing.
The issue I have is that the cm updater looks to be looking at latest nightly releases and probably date. In the updater are 10.1-2013....nightlies and not 10.1.0-2013..... Nightlies
I am spoiled by this option with the cm rom.
The updater just goes off and does its thing and updates cm. I wish that other ROMs had this option.
TDM Since PAC is built off of CM, do you think it could be possible to include the updater and point it to PAC updates.
tdm
Android Expert
The PAC team is working on an updater.
IMUcarmen
Android Expert
Haha thats the only difference I can find, but it seems that sosaudio thinks they are different and is looking for 10.1.0 nightlies now since thats what the RC was labeled.
I guess I wanted more or less clarification. Wasn't sure if the 10.1.0-RC2 was going to be the next bleeding edge rom.
Soo in my mind, cm-10.1.0-RC2 should be higher than cm-10.1-20130522-NIGHTLY because of the added revision number the .0
If it isn't then ok....but I just wanted to make sure I was getting the latest and not going backwards.
THIS IS NOT HOW CM BUILDS ARE NUMBERED... Just a bit of rant. I wanted to make sure I put that at the begining... so that I didn't cause confusion.
Technically, there's no standard way for version numbering. There are some schemes that address realease candidates... For instance wikipedia says this: Software versioning - Wikipedia, the free encyclopedia
Unfortunately, versioning schemes like this wouldn't adapt well to something with nightly builds or frequent builds.
I guess they could do something like 10.1.1.20130521 (version.change.beta(nightly).sequential build number(date))
Though, that could get a bit unwieldy.
Of course, that would make it difficult as well, since you would end up with RC's being like 10.1.2.1 for RC1 or 10.1.2.2 for rc2.
So you'd end up with something like (sequentially by build date)
10.1.1.20130521
10.1.2.1
10.1.1.20130523
Even though the last one actually has newer code than the one above it, the version would look older.
Though if they did it like....
10.1.1.20130521 (nightly)
10.1.2.20130522 (RC)
10.1.1.20130523 (nightly)
10.1.2.20130524 (RC)
10.1.3.20130525 (Release)
You could form some sort of update system based on the third number as well as the build date. IE: Stable Only; Semi Stable or Stable; Experimental, Semi stable, or Stable. Where stable would only look for builds with 10.1.3 with whichever has the newest date being newest. Semi taking 10.1.2 or 10.1.3, and experimental taking anything based on the date.
Just my 2 cents.
Though, to be fair... Given the numbering schemes described there, your question makes perfect since as 10.1.0RC2 would be like an RC2 for an alpha build
THIS IS NOT HOW CM BUILDS ARE NUMBERED... Just a bit of rant. I wanted to make sure I put that at the begining... so that I didn't cause confusion.
Technically, there's no standard way for version numbering. There are some schemes that address realease candidates... For instance wikipedia says this: Software versioning - Wikipedia, the free encyclopedia
Unfortunately, versioning schemes like this wouldn't adapt well to something with nightly builds or frequent builds.
I guess they could do something like 10.1.1.20130521 (version.change.beta(nightly).sequential build number(date))
Though, that could get a bit unwieldy.
Of course, that would make it difficult as well, since you would end up with RC's being like 10.1.2.1 for RC1 or 10.1.2.2 for rc2.
So you'd end up with something like (sequentially by build date)
10.1.1.20130521
10.1.2.1
10.1.1.20130523
Even though the last one actually has newer code than the one above it, the version would look older.
Though if they did it like....
10.1.1.20130521 (nightly)
10.1.2.20130522 (RC)
10.1.1.20130523 (nightly)
10.1.2.20130524 (RC)
10.1.3.20130525 (Release)
You could form some sort of update system based on the third number as well as the build date. IE: Stable Only; Semi Stable or Stable; Experimental, Semi stable, or Stable. Where stable would only look for builds with 10.1.3 with whichever has the newest date being newest. Semi taking 10.1.2 or 10.1.3, and experimental taking anything based on the date.
Just my 2 cents.
Though, to be fair... Given the numbering schemes described there, your question makes perfect since as 10.1.0RC2 would be like an RC2 for an alpha build
Yeah and that's where I was because we came from the 10.1...yada yada to 10.1.0. So again, pardon my ignorance on cm releases, but it looked like a change for something that was coming. For me I would, until stable, say 10.1.0 to 10.1.9 then the new version would be 10.2. From there the nightlies follow the rules of what we have now.
So... cool... I will keep downloading and installing nightlies thru the updater and rock on.
Which would make sense.... Except that the CM build numbers are based off of android.
I believe:
CM10 was android 4.1
CM10.1 is android 4.2.2
If CM jumped to 10.2 without android updating from 4.2.2... it would shatter the whole numbering scheme
tdm
Android Expert
The cm major version is the position of the first letter of the android code name in the alphabet.
The cm minor version is the release number of that android version: mr1 = .1
The cm point version is at cm's discretion.
Any version component not present is equivalent to Zero.
Nightly builds are just previews of their eventual releases.
The cm minor version is the release number of that android version: mr1 = .1
The cm point version is at cm's discretion.
Any version component not present is equivalent to Zero.
Nightly builds are just previews of their eventual releases.
Same here. CM did this a few nightlies ago.... Hang loose with the nandroid you have or stay with the 522 nightly. TDM is probably looking into it now
Probably just a bad build.
Thats part of the fun of flashing nightlies.
If it persists though for more than a nightly or two, it's definitely an issue.