Version Control system, and branches. In a simple model, branch it and merge the changes back later. The software will handle the differences painlessly most of the time, though the merged version could still go wrong anyway.
Last edited:
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.
Work Continues on iOS 8.1.3 With Retail Employees Receiving Second Beta Seed
- Thread starter MacRumors
- Start date
- Sort by reaction score
They need to move on to ios 9 give it a fresh look 8 has bombed there trying to make up.
The changes from the 8.1.x branches get merged forward into the 8.2 branch. And the 8.2 branch gets merged forward into the 9.0 branch (which - yes - they are already working on).
If the exact same lines are changed in different branches - there will be a merge conflict that has to be resolved. Otherwise the revision control systems (think svn/git) merge the changes in the files automatically based on file location and time stamp.
Last edited:
Well, that's how it is supposed to work. But, integration bugs at each merge are sadly non trivial in very large projects. That's why the actual coding part of large development projects on new platforms is often not the biggest expense.
I believe he asked how it was supposed to work. Unless he's a software engineer - I don't think he was asking about the finer details of merge conflicts / resolution. And if he *was* a software engineer - I don't think he would have asked the question to begin with.
If you want to provide a helpful, explanatory post on merge conflicts, how / why they arise, and how they are dealt with - for the lay person - feel free.
Last edited:
I believe he asked how it was supposed to work. Unless he's a software engineer - I don't think he was asking about the finer details of merge conflicts / resolution. And if he *was* a software engineer - I don't think he would have asked the question to begin with.
If you want to provide a helpful, explanatory post on merge conflicts, how / why they arise, and how they are dealt with - for the lay person - feel free.
I wasn't arguing about the usefulness of the info for a lay person. The comment was more for yourself. If it was that easy, then I'd just clear out half the staff and always call it a day at 5pm
.Wish bad merges could all be resolved by simply telling people RTFM instead of exorcising the spaghetti monster that lives in all errant code/systems
. Of course, we could just back it out... But, eventually, especially when there are a lot of dependencies, financial limitations and tight deadlines, the code has to go in... Hopefully well polished by that time.
Honestly, when does Apple completely overhaul the basic look of iOS? Will it be with iOS 10, perhaps? (After all, the overall aesthetics are getting a tad stale by today's standards.) So let me put it this way; when will Apple stop gearing the current look of iOS to its lowest common denominator consumer base? You know, the Luddites who's kids talked them into getting iPhones. The same people who can't work a microwave. Simple is better I get it. Simple doesn't need to be boring however.
+ 1 on that. Im glad someone else noticed it.
----------
Never. iOS will be aimed at the LCD, and that is a good thing, it caters to most of the users. These people want simple and "it just works"
If you want something that you can tinker with, android is your answer.
Otherwise your stuck in no mans land, complaining that Apple is dumbing it down etc..... Though year by year it becomes less the company it began, computers, these days it's about lifestyle, apple makes devices for day to day use.
I believe he asked how it was supposed to work. Unless he's a software engineer - I don't think he was asking about the finer details of merge conflicts / resolution. And if he *was* a software engineer - I don't think he would have asked the question to begin with.
If you want to provide a helpful, explanatory post on merge conflicts, how / why they arise, and how they are dealt with - for the lay person - feel free.
There are lots of tools available. Apple will be using some sort of SVN : software versioning and revision control system. Branching and merging is very common in development these days.
Also the term software engineer..... Is a load of rubbish, I've been in software development for over 15 years, and everytime I hear a developer say they are a software engineer I remind them that I am so glad software engineers don't build bridges or planes, cause software is the only engineering is the only are you can release something that is filled with huge bugs. I just struggle to associate engineering with just poor QA. Once worked with a an aeronautical engineer, if devs were are focused and committed to QA and checking everything , we would have Amazing software.
Sorry pet peeve of mine, sadly IT is one of the worst abused places with stupid titles that do not reflect the actual job..... Enterprise architect .... Lol.
----------
That's not a very good illustration to show branching, as its from a developer point of view. I have not got time at the moment, though you need an illustration showing how "trunk" and branches work. there are no live brances, once live it goes into trunk, which this illustration kinda suggests
Understood, but would an "optional" customizable homescreen kill Apple and iOS' simplicity. (For the advanced users of course.) Apple's been incorporating more minute details and options with in the past two iOS releases, so perhaps by iOS 10, this may be a possibility.
Or maybe they folded the features intended for 8.3 back into 8.2.
----------
Source code management systems provide the ability to "branch" from the main "trunk" of the tree. 8.1.3 would be a branch of the tree.
At some point in the future, the 8.1.3 branch will be merged back into the main "trunk", and will become part of 9.0.
It's not a totally automated process, as there are inevitably conflicts --- especially if a 9.0 developer substantially rewrites a module.
I once wondered about why software "engineering" was so hard. As you have pointed out, it's not a rigorous discipline, especially compared to aeronautical and civil engineering.
I think one reason is because software is so EASY to change. When you can easily iterate through multiple change/test cycles, there is less incentive to carefully consider the consequences BEFORE you make the change.
But, I think the real difference is potential complexity. Physical embodiments of electrical circuits, bridges, etc. are constrained by the laws of physics, or manufacturing processes, etc. However, there is very little constraint on complexity of software these days. In the past, you were limited by RAM and processor speed (and lots of other issues) -- these have been growing exponentially, thus enabling more complex software.
Unfortunately, our ability to manage complex software hasn't really kept up with our ability to create complex software.
I wasn't arguing about the usefulness of the info for a lay person. The comment was more for yourself. If it was that easy, then I'd just clear out half the staff and always call it a day at 5pm
Wish bad merges could all be resolved by simply telling people RTFM instead of exorcising the spaghetti monster that lives in all errant code/systems
Well, thanks for the feedback - but *I* certainly don't need it. If it was that simple *I too* would simply clear out the staff and go home at 5pm. My 90 second post was just to give some high level response to the person that asked the question. I find the pedantic attacks in theses forums amusing. Why not simply add additional clarity for the other user if you feel you can contribute / add more instead of telling me where my "simple answer" fell down, assuming what I don't know vs what I haven't taken the time to explain?
Most people calling themselves software engineer don't have an engineering degree, but a computer science one (or no degree at all)!! Most IT staff, web coders are barely technicians let alone engineers!
The main reason software is crap is that nobody's willing in the consumer sphere to pay for good software (or people who actually know what they are doing). Simple as that. People are complaining about the cost (and pirating), $1 software, that should telling you something.
The amount of feature change is also extremely high in the consumer space. Locking down specs to the minimum so you can actually make it without major faults seems to not be worth it for most companies; for marketing reasons they need to cover a list of features; the public seemingly doesn't give a crap. High amount of features and little time to develop them makes for a predictable outcome.
Though, as a sort of defense for their failings, the consumer space systems interact with a broader range of external devices/environments/users/use cases than their more narrowly focused big brother.
But, that alone should make them wary of increasing the scope of their projects, yet it doesn't.
Well - considering my education is in Computer Science and Applied Math - and almost every single "title" I've held over the last 20 years had "software engineer" in it - I guess I'll keep using the industry standard / approved / and understood expression. Feel free to continue nursing your pet peeve though. Also, perhaps the problem is the fact you work in "IT". I've never worked in the "IT" department. Well, except when I was in my early 20s - but, that was a college thing as a campus wide Systems Administrator. (That title's not a pet peeve of yours too, is it?
)Feel free to post your own illustration illuminating your vast knowledge on the subject - in a way that provides additional understanding / value to the lay person in the forum. I think my quick post answered his question - and if I recall - "I" didn't ask one. But, thanks for all the replies all the same.
I hope they fix the missing album art in Apple Remote.
True, although Engineering Schools do now have Software Engineering programs in Canada - so it's a real title. Whether or not these software engineers are any better than computer scientists is a matter of debate
----------
Yes, merging can be painful if multiple conflicting changes are introduced into multiple branches.
You can test this out on your own computer. Edit multiple version of a Word document then do a file comparison / merge - sometimes it'll be fine, other times it'll take a keen eye to merge the changes together.
True, although Engineering Schools do now have Software Engineering programs in Canada - so it's a real title. Whether or not these software engineers are any better than computer scientists is a matter of debate
----------
Yes, merging can be painful if multiple conflicting changes are introduced into multiple branches.
You can test this out on your own computer. Edit multiple version of a Word document then do a file comparison / merge - sometimes it'll be fine, other times it'll take a keen eye to merge the changes together.
It's just a snapshot from Google Analytics. But you are correct, the lack of detail leaves much to be desired in terms of qualitative journalism. Obviously they don't want the general public to know exactly how many visitors of any sort go to their website as it is considered competitive data, but they could show a ratio versus the actual data.
Even then they'd be giving away more data than they probably should. Personally I wouldn't post a damn thing from Google Analytics. Too intimate.
----------
Well said and true in most cases. However, Apple has deviated from their standard code management practices when they've worked on extremely confidential releases. This did create conflicts which required resolution.
(basically, silo'ed developers working on old code bases for new features.)
