This means nothing. Mountain Lion in 1000x better than Lion, but had fewer builds.
Another way to look at it: Bugs, bugs everywhere. Take your time Apple, make it as stable as possible.
They don't have nearly the amount of bugs as Windows. Look up the various versions of OS X and the various versions of Windows on Wikipedia, they list the release date and the stable release date. It's interesting to see how long it takes for Windows to become "stable".
It only makes no sense if you've never used continuous integration and automated unit/regression testing after each commit. On the other hand, this is quite a common thing to use for software groups that work on complex pieces of software, such as an OS, do.
If they are incrementing that build number after every commit that strikes me as a fairly low number even if staging from a subsystem repo to master. CI implies a lot of commits. 451 strikes me as a nightly build + extras when desired.
Maps was accurate in your area not because of developers giving Apple feedback, but because the people there are more likely to jump on new technology first, this would include using something like OpenStreetMap and giving feedback to them.
Apple uses OpenStreetMap data, along with many, many other public databases around the world for its location information (Google uses these as well to update its own database). There is no reason for a "beta" version. Apple's Maps worked fine. The small number of instances of inaccuracies were blown way out of proportion by people who scream "bomb" when a firecracker is lit.
Google's data has many errors as well, but no one really cared, they just reported it to Google and went on their merry way. No one made a big deal about it. Mapping data is EXPECTED to have errors and not be complete as new roads are constantly being changed, torn up and built, etc., etc.
A big deal was made when Apple dumped Google's Maps because some people wanted -- no, like to see Apple to fail, so every little issue went under the microscope.
The issue with Maps wasn't the mere presence of errors. There is likely not a database in the world without errors. It was the number of errors or missing POIs coupled with the forced change from a database with far fewer errors or missing POIs.
I live on the otherwise of the country and frankly maps has worked great every time I've used it. It often got skewered in the media due to data base errors that every GPS based mapping system has had or does have to this day. In the end much of the complaining about maps was either based own ignorance or a mischievous attempt to harm Apple. A rational look at Maps would have people seeing a well done version one app.
Maps was ready from day one, it does precisely what a mapping program should do.
Sometimes that user feedback is more damaging than helpful. You could see this in places data where users obviously screwed up in one manner or another.
If you looked at complaints closely, at release, it wasn't an issue of maps not working it was either data base issues or unreasonable expectations. For one it was totally unreasonable of people to expect that Apple would release a maps app that copied Googles solution 100%. It is this expectation that frankly lead to a lot of drizzle on the net about nothing. It amounted to complaining about Pages because it doesn't work like MS Word.
It is funny that people get so bent out of shape over Maps which works well for most users and gloss over iCloud which for most users is a big disappointment. For whatever reason Maps got elected to be the punching bag.
I don't think anybody would argue that the application was a fine application from a UI perspective, but the purpose of a mapping application IS the database. It was not unreasonable in the least to expect Apple to allow users to keep as default a mapping database with much more complete information.
You have no reason to say that at all. First; on modern hardware you can rebuild an entire OS rather quickly, they could hit the build button at lunch time for example. I wouldn't be the least bit surprised to find builds happening on a large cluster to cut build times even further. Beyond that if they are working on one component a rebuild might just be limited to code for what is being worked on.
Yes it is sad! I really don't understand your point of view though, you have no reason at all to believe that Apple can only manage one build a day. I wouldn't be surprised to find that Apple has the ability to rebuild the entire Mac OS code base several times a day if they really wanted too.
Sure. You have a build farm that can build quickly and then regression test which usually takes longer. With a large build farm you can generate a new build after every commit. I just don't believe that 451 is the kind of build number you end up with in those scenarios. For that you usually see something like date+build number. In other words you end up with build 2013060645 (45th build on June 6, 2013).
For a nightly build I'd assume they'd run their regression tests on every supported architecture/configuration in their test farm.
451 builds for an OS release sounds pretty danged good even at once per day.
More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.
Thats what most CI shops do. There's not much need to do it more than once a day unless there's some critical bug being stomped.
Many systems you check into a staging repo and the CI system builds, regression tests and then checks it into the trunk for you. You never get to commit to the mainline manually.
I am pointing out the absurdity in your argument about "knowing" how integrated builds work.
If there are 451 builds of OS X it took 451 days. Minimum.
Nothing bugs me more than sneering statements from people who have no clue.
One could also point out there is an absurdity in your argument about 'knowing' how Apple works. Yes it seems most logical for them to build overnight but perhaps they don't. perhaps they don't build every 24 hours but rather sometimes every 12 even every 2. and sometimes not for a whole week.
It's impossible to release a bug free OS of this level. Because in order to actually test and OS, you have to put it on every computer/third party hardware and software and test it. It's IMPOSSIBLE to do that. But, releasing it to the developers ahead of time gives them the chance to update their software, test it as best as they can so the third party developers have their updates within a couple of months after the OS is released to the customer. Haven't you noticed that Apple is having less updates per major release? They just released 10.8.4. in about 9 months. I'm sure when 10.9 comes out, they might have or need 10.8.5, but they also might not need to update it. 10.7 had 5 builds. 10.6 had 8 builds. 10.5 had 8 builds. 10.4 had 11 builds. 10.3 had 9 builds. 10.2 had 8 builds. 10.1 had 5 builds. 10.0 had 4 builds.
So, it looks like Apple is doing much better in getting to a bug free release.
The numbers don't back up your hypothesis. If you ignore the fact that Snow Leopard, Lion and Mountain Lion have all had one or more OS release bearing the same number as the one that preceded it, the pace of OS releases today is the same as it was during the Tiger/Leopard years. If you count the supplemental releases, as I've done, the lifespan of a recent OS X version looks more like Jaguar/Panther.
Apple has done 72 OS X releases in a span of 4458 days. Each release has remained current for an average of 62 days. The variation by major version number can be seen in the table below.
10.0: 5 releases - 186 days One per 37 days
10.1: 6 releases - 334 days One per 56 days
10.2: 8 releases - 427 days One per 53 days
10.3: 10 releases - 554 days One per 53 days
10.4: 12 releases - 911 days One per 76 days
10.5: 9 releases - 673 days One per 75 days
10.6: 11 releases - 692 days One per 63 days (I've counted 10.6.3 v1.1 and 10.6.8 v1.1 in the total)
10.7: 6 releases - 372 days One per 53 days (I've counted 10.7.5 supplemental)
10.8: 5 releases - 317 days One per 63 days (I've counted 10.8.2 supplemental)
Finally I would say that the pace of maintenance releases is most likely an indication of the amount of time Apple assigns to developing and testing a new version of the OS. The 62 day average is probably the combination of well planned 3 month schedules and 3 week emergency fixes.
Apple builds its own machines, it does not build all the hardware within those machines. Ever seen the errata list for, say, an Intel CPU? They can sometimes be massive. Also, not all hardware bugs will plainly manifest themselves when doing development work and sometimes do not manifest until the software is in the wild and being used by regular users. So it's perfectly reasonable and easy to attribute certain issues in the OS with hardware bugs especially when they only manifest during weird edges cases (as many do).
I agree with what you said, but the poster I was replying to made it sound like Apple had to test their OS on the near infinite number of hardware combinations that windows or linux have to accomodate. While Apple does not control the construction of the internal components, its OS only has to work on its own pre-selected combinations of components (peripheral devices notwithstanding). So the scale of its third-party hardware problem is much smaller.
All the speculation on how Apple does builds is meaningless... you do not know how they do it.
I work on large projects and we have builds set to go off automatically every 15 minutes 24/7 if anyone has committed a change to the code. If a problem comes back from the build, testing, or whatever... it informs everyone including the people that checked in the code, and it needs to be fixed ASAP, no matter the time of day.
The more often you make builds and have them tested, the easier it is to narrow down on what may have caused a new problem.... when you have a huge server farm with plenty of power, its not that difficult to do, multiple builds of the same stuff going at the same time even.
We do NOT know how Apple does build numbers. I've seen shops use multiple build number systems... where internal 50 builds in a day use a different number scheme, and 1 main build each day (or more often as needed) gets a "build number" that is shared more publicly, using a simpler numbering scheme.
This is all wild speculation on our parts on how Apple does it, and what numbers they start with. Even if we are to guess correctly... its just build numbers, it tells us very little. If they are daily builds and its number 451.... whats to say 20 of those builds had no changes at all...?
I want 10.9 to be all optimization like Snow Leopard was. The only feature request I have is to let us customize our notifications. Basso does not please me. I also don't want birthdays from Facebook to pop up as notifications.
Same here. Especially when I'm submerged into Full Screen. I cannot believe they actually thought that was something people wouldn't want and had an option to turn off. So I turned off Notifications off altogether. Also on my iPad, as I have my iPhone with me all the time.
Comments
Quote:
Originally Posted by pedromartins
This means nothing. Mountain Lion in 1000x better than Lion, but had fewer builds.
Another way to look at it: Bugs, bugs everywhere. Take your time Apple, make it as stable as possible.
They don't have nearly the amount of bugs as Windows. Look up the various versions of OS X and the various versions of Windows on Wikipedia, they list the release date and the stable release date. It's interesting to see how long it takes for Windows to become "stable".
Quote:
Originally Posted by Applelunatic
It only makes no sense if you've never used continuous integration and automated unit/regression testing after each commit. On the other hand, this is quite a common thing to use for software groups that work on complex pieces of software, such as an OS, do.
If they are incrementing that build number after every commit that strikes me as a fairly low number even if staging from a subsystem repo to master. CI implies a lot of commits. 451 strikes me as a nightly build + extras when desired.
Quote:
Originally Posted by mjtomlin
Maps was accurate in your area not because of developers giving Apple feedback, but because the people there are more likely to jump on new technology first, this would include using something like OpenStreetMap and giving feedback to them.
Apple uses OpenStreetMap data, along with many, many other public databases around the world for its location information (Google uses these as well to update its own database). There is no reason for a "beta" version. Apple's Maps worked fine. The small number of instances of inaccuracies were blown way out of proportion by people who scream "bomb" when a firecracker is lit.
Google's data has many errors as well, but no one really cared, they just reported it to Google and went on their merry way. No one made a big deal about it. Mapping data is EXPECTED to have errors and not be complete as new roads are constantly being changed, torn up and built, etc., etc.
A big deal was made when Apple dumped Google's Maps because some people wanted -- no, like to see Apple to fail, so every little issue went under the microscope.
The issue with Maps wasn't the mere presence of errors. There is likely not a database in the world without errors. It was the number of errors or missing POIs coupled with the forced change from a database with far fewer errors or missing POIs.
Quote:
Originally Posted by Tallest Skil
Ha! Nonsense. A final build given to devs?
It's a joke.
Quote:
Originally Posted by wizard69
I live on the otherwise of the country and frankly maps has worked great every time I've used it. It often got skewered in the media due to data base errors that every GPS based mapping system has had or does have to this day. In the end much of the complaining about maps was either based own ignorance or a mischievous attempt to harm Apple. A rational look at Maps would have people seeing a well done version one app.
Maps was ready from day one, it does precisely what a mapping program should do.
Sometimes that user feedback is more damaging than helpful. You could see this in places data where users obviously screwed up in one manner or another.
If you looked at complaints closely, at release, it wasn't an issue of maps not working it was either data base issues or unreasonable expectations. For one it was totally unreasonable of people to expect that Apple would release a maps app that copied Googles solution 100%. It is this expectation that frankly lead to a lot of drizzle on the net about nothing. It amounted to complaining about Pages because it doesn't work like MS Word.
It is funny that people get so bent out of shape over Maps which works well for most users and gloss over iCloud which for most users is a big disappointment. For whatever reason Maps got elected to be the punching bag.
I don't think anybody would argue that the application was a fine application from a UI perspective, but the purpose of a mapping application IS the database. It was not unreasonable in the least to expect Apple to allow users to keep as default a mapping database with much more complete information.
Quote:
Originally Posted by wizard69
You have no reason to say that at all. First; on modern hardware you can rebuild an entire OS rather quickly, they could hit the build button at lunch time for example. I wouldn't be the least bit surprised to find builds happening on a large cluster to cut build times even further. Beyond that if they are working on one component a rebuild might just be limited to code for what is being worked on.
Yes it is sad! I really don't understand your point of view though, you have no reason at all to believe that Apple can only manage one build a day. I wouldn't be surprised to find that Apple has the ability to rebuild the entire Mac OS code base several times a day if they really wanted too.
Sure. You have a build farm that can build quickly and then regression test which usually takes longer. With a large build farm you can generate a new build after every commit. I just don't believe that 451 is the kind of build number you end up with in those scenarios. For that you usually see something like date+build number. In other words you end up with build 2013060645 (45th build on June 6, 2013).
For a nightly build I'd assume they'd run their regression tests on every supported architecture/configuration in their test farm.
451 builds for an OS release sounds pretty danged good even at once per day.
Quote:
Originally Posted by mjtomlin
More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.
Thats what most CI shops do. There's not much need to do it more than once a day unless there's some critical bug being stomped.
Many systems you check into a staging repo and the CI system builds, regression tests and then checks it into the trunk for you. You never get to commit to the mainline manually.
Quote:
Originally Posted by asdasd
Unless Apple run their large OS on shifts - which I doubt - they build overnight.
which, if the number is correct, might mean that they have been working on this version for a while. before Lion launched.
Quote:
Originally Posted by asdasd
I am pointing out the absurdity in your argument about "knowing" how integrated builds work.
If there are 451 builds of OS X it took 451 days. Minimum.
Nothing bugs me more than sneering statements from people who have no clue.
One could also point out there is an absurdity in your argument about 'knowing' how Apple works. Yes it seems most logical for them to build overnight but perhaps they don't. perhaps they don't build every 24 hours but rather sometimes every 12 even every 2. and sometimes not for a whole week.
unless you are an Apple engineer you don't know
Quote:
Originally Posted by drblank
It's impossible to release a bug free OS of this level. Because in order to actually test and OS, you have to put it on every computer/third party hardware and software and test it. It's IMPOSSIBLE to do that. But, releasing it to the developers ahead of time gives them the chance to update their software, test it as best as they can so the third party developers have their updates within a couple of months after the OS is released to the customer. Haven't you noticed that Apple is having less updates per major release? They just released 10.8.4. in about 9 months. I'm sure when 10.9 comes out, they might have or need 10.8.5, but they also might not need to update it. 10.7 had 5 builds. 10.6 had 8 builds. 10.5 had 8 builds. 10.4 had 11 builds. 10.3 had 9 builds. 10.2 had 8 builds. 10.1 had 5 builds. 10.0 had 4 builds.
So, it looks like Apple is doing much better in getting to a bug free release.
The numbers don't back up your hypothesis. If you ignore the fact that Snow Leopard, Lion and Mountain Lion have all had one or more OS release bearing the same number as the one that preceded it, the pace of OS releases today is the same as it was during the Tiger/Leopard years. If you count the supplemental releases, as I've done, the lifespan of a recent OS X version looks more like Jaguar/Panther.
Apple has done 72 OS X releases in a span of 4458 days. Each release has remained current for an average of 62 days. The variation by major version number can be seen in the table below.
10.0: 5 releases - 186 days One per 37 days
10.1: 6 releases - 334 days One per 56 days
10.2: 8 releases - 427 days One per 53 days
10.3: 10 releases - 554 days One per 53 days
10.4: 12 releases - 911 days One per 76 days
10.5: 9 releases - 673 days One per 75 days
10.6: 11 releases - 692 days One per 63 days (I've counted 10.6.3 v1.1 and 10.6.8 v1.1 in the total)
10.7: 6 releases - 372 days One per 53 days (I've counted 10.7.5 supplemental)
10.8: 5 releases - 317 days One per 63 days (I've counted 10.8.2 supplemental)
Finally I would say that the pace of maintenance releases is most likely an indication of the amount of time Apple assigns to developing and testing a new version of the OS. The 62 day average is probably the combination of well planned 3 month schedules and 3 week emergency fixes.
Quote:
Originally Posted by ghostface147
That would be a rather short time to test. Even more so since they've pulled devs off of OS X to work on iOS 7.
Maybe the *reason* they pulled devs off OS X to help with iOS was that OS X was nearly finished anyway.
Quote:
Originally Posted by Applelunatic
Apple builds its own machines, it does not build all the hardware within those machines. Ever seen the errata list for, say, an Intel CPU? They can sometimes be massive. Also, not all hardware bugs will plainly manifest themselves when doing development work and sometimes do not manifest until the software is in the wild and being used by regular users. So it's perfectly reasonable and easy to attribute certain issues in the OS with hardware bugs especially when they only manifest during weird edges cases (as many do).
I agree with what you said, but the poster I was replying to made it sound like Apple had to test their OS on the near infinite number of hardware combinations that windows or linux have to accomodate. While Apple does not control the construction of the internal components, its OS only has to work on its own pre-selected combinations of components (peripheral devices notwithstanding). So the scale of its third-party hardware problem is much smaller.
All the speculation on how Apple does builds is meaningless... you do not know how they do it.
I work on large projects and we have builds set to go off automatically every 15 minutes 24/7 if anyone has committed a change to the code. If a problem comes back from the build, testing, or whatever... it informs everyone including the people that checked in the code, and it needs to be fixed ASAP, no matter the time of day.
The more often you make builds and have them tested, the easier it is to narrow down on what may have caused a new problem.... when you have a huge server farm with plenty of power, its not that difficult to do, multiple builds of the same stuff going at the same time even.
We do NOT know how Apple does build numbers. I've seen shops use multiple build number systems... where internal 50 builds in a day use a different number scheme, and 1 main build each day (or more often as needed) gets a "build number" that is shared more publicly, using a simpler numbering scheme.
This is all wild speculation on our parts on how Apple does it, and what numbers they start with. Even if we are to guess correctly... its just build numbers, it tells us very little. If they are daily builds and its number 451.... whats to say 20 of those builds had no changes at all...?
Same here. Especially when I'm submerged into Full Screen. I cannot believe they actually thought that was something people wouldn't want and had an option to turn off. So I turned off Notifications off altogether. Also on my iPad, as I have my iPhone with me all the time.