Where is the evidence that they're "waiting for them to get lumped in with other bugfixes?"
Because testing six releases is supposed to happen faster than testing one?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Considering updates are now OTA, shouldn't Apple be updating phones more frequently?
- Thread starter Calidude
- Start date
- Sort by reaction score
personally I don't want Apple to go down the bitty patch route, like Microsoft have done.
When I was using Windows PCs updates were a bane of my life, once you've updated this, you have to update it again with the next version, which was dependent on the first.
Even though I admire Apple for going down the delta path for on the air uploads, but I have not updated my iphone to 5.01 yet.
with OTA, I guess I would have to update to 5.01, then I'll be able to update to 5.1.
Nah, I'd prefer to download the full update 5.1 and update from desktop. Im only doing the .x releases this time, not the .xx
When I was using Windows PCs updates were a bane of my life, once you've updated this, you have to update it again with the next version, which was dependent on the first.
Even though I admire Apple for going down the delta path for on the air uploads, but I have not updated my iphone to 5.01 yet.
with OTA, I guess I would have to update to 5.01, then I'll be able to update to 5.1.
Nah, I'd prefer to download the full update 5.1 and update from desktop. Im only doing the .x releases this time, not the .xx
You just defeated your own point. It has taken them this long to bring out this new release that, by all appearances, brings nothing new to the table except for bug fixes.
This is an indication that the bugs which need fixing are complicated, and it is taking them a long time to make sure that the fixes are adequate (they actually fix the bugs in question) and that they do no harm (nothing would hurt their public perception more than releasing a bug fix that inadvertently causes a whole new set of bugs to come to the surface.)
In an integrated system, changes to one component can sometimes have unexpected interactions with other components. If they released a fix to one bug immediately, they could very easily be shooting themselves in the foot by making the next bug on their radar that much more difficult to correct, forcing them to subsequently backtrack on the other recent fixes that came before and attack them by a different means.
By making sure that all of the changes currently on their short-range radar play well with one another, before pushing out any of them, I suspect that they are probably improving their overall average response time over the long term.
It's an indication, but it doesn't mean that this is actually what is happening.
sorry but this is just screaming naivety and ignorance. as a developer theres no way i would want tons of point releases pushed out "immediately" OTA. sorry but this isn't wordpress where plugins break ALL of the time with each new point release.
I never said that they should be pushed immediately OTA. They can be tested just like 5.0.1 and then pushed out.
But Steve's point is that developers don't want to spend their time continually testing if apple decided to make lots of point releases. Its difficult to keep a stable platform by pushing out so many bug fixes in a short time span as well.
In the end, I think the work required to fix the bugs, test internally and externally is evident as to why the cycle has not changed.
I'm not saying that we should have bugfixes out every week or even two weeks. I'm just saying that OTA updates should have made it easier to push out critical bugfixes to users sooner than how it is now, rather than waiting for a huge release.
Wirelessly posted (Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3)
As someone who is just getting into programming I disagree and agree, from my studies, I understand that programmers constantly revise their code, they want updated versions of their code out as soon as possible, then move onto the next build, however in apple terms, we don't know what extra features are coming they need to test, test again, test even more,and test again, these tests should last weeks, as bugs can appear through different use of the phone, on the other hand, with their mOney, I'm surprised at how long it is taking for apple to dish out improvements, and extra rumoured features, but that's speculation, I would guess we'll see one or two new features but that's it..
As someone who is just getting into programming I disagree and agree, from my studies, I understand that programmers constantly revise their code, they want updated versions of their code out as soon as possible, then move onto the next build, however in apple terms, we don't know what extra features are coming they need to test, test again, test even more,and test again, these tests should last weeks, as bugs can appear through different use of the phone, on the other hand, with their mOney, I'm surprised at how long it is taking for apple to dish out improvements, and extra rumoured features, but that's speculation, I would guess we'll see one or two new features but that's it..
My point is that in order to get those out sooner, apple needs to test those internally and externally. So instead of providing the developers with a set of bug fixes to test once, they send out multiple bug fixes to the developers to test. By decreasing the update cycle and increasing the number of updates, you increase the workload for the developer because he has to test each and every bug fix individually instead of a single update that contains multiple bug fixes
Dude, I'm not saying every SINGLE fix needs to be pushed out separately. Come on, why would anybody do that? I'm saying a huge set of bugfixes need to be prioritized and split into smaller groups of fixes. Instead of 100 fixes per update, it should be 30 critical fixes for one update, 30 less important fixes for another, and save the least important fixes to be grouped with an update with new features.
