Page 2 of 2 FirstFirst 12
Results 21 to 27 of 27
  1. #21  
    Quote Originally Posted by jbg7474 View Post
    Forgive me, but I would very much like it to be different from the way HTC manages Windows Mobile devices. Ideally, the code that exists at Palm is in two buckets: WebOS and carrier specific configurations. I hope dearly that every WebOS device ever developed has the same WebOS on it, assuming that it's updated. I want the core of WebOS to be managed in a single configuration so that Palm doesn't have to worry about slightly different configurations of the mail app, for instance, for Sprint vs. Bell vs. Verizon (eventually). That would be a huge headache.

    Instead of the huge headache, managing everything in WebOS, and then in separate carrier configurations makes it all clean. It's much less wasted effort for developers. The carrier configs need to be separate.

    Yes, the build number may very well be the particular combination of WebOS with the carrier configuration, and I hope that it is. I'm not trying to be alarmist here. I'm just saying that what Ronlongo suggested, that WebOS itself is branched, would be a disaster for the future of WebOS. Okay, perhaps that's a bit alarmist. I guess I feel it's worthy of an alarm.
    Branching doesn't imply disaster. Branching is simply one way of managing multiple configurations; it keeps the configurations logically separated.

    For Example, we branch here at work all the time. Every time we plan a new release of our software, the first thing we do is branch. We often have several branches in development at once. The separate branches insure intermediate modifications in each development effort don't interfere with eachother. Once a development branch is tested and finalized, its changes are incorporated back into the main line.

    Hence, Palm could simply be branching to manage various configurations of WebOS. Sharing the core code between branches is trivial. If Palm is branching their repository for various builds, it's very unlikely that branch specific changes will be reincorporated into the main line. This doesn't mean that changes to the core will not be merged back into the main line. However, branching allows the developer to checkout a specific configuration from their repository for testing and subsequent distribution.

    For very large software development projects, configuration management via branching is a GOOD thing. That's precisely what the concept of branching was developed for.
    Last edited by ronlongo; 08/27/2009 at 01:59 PM.
  2. #22  
    pandora dosen't work outside of US
  3. #23  
    Quote Originally Posted by jbg7474 View Post
    If this is true, I think that's a bad thing. And managing multiple branches by build number would be a bad way to do it. I hope that the build number is a build of WebOS1.1 with the Bell configuration rather than just the WebOS part. If they start branching WebOS for different carriers, they have no hope of keeping up with maintenance of this puppy. Managing things separately with an OS core and an extra package that includes configuration items for separate carriers seems like a much, much better way to go. I really hope that's what they're doing.
    I very much doubt that Palm is managing source code from the point of a Build Number. I work on several software development efforts in both a CM and developer role. Any revision control system I've ever used (quite a few) know nothing about build numbers. Modern revision control typically tracks source code via revision numbers. A revision number is a counter in the revision control system. In the case of a system such as subversion, every time changes to any file are committed to the repository, the counter is incremented and the new version of the file is given the new revision number. If you want to check out a set of source code form the repository it's possible to supply a revision number and a complete build corresponding to that revision will be downloaded from the repository.

    From the CM position almost EVERYTHING is done by revision number. It's not a bad thing, it's a good thing. Revision numbers allow us to extract a complete build from the repository for any branch and point in time in the development process. Revision numbers are truely the best tool available for managing source code across multiple branches in a repository.
    Last edited by ronlongo; 08/27/2009 at 02:14 PM.
  4. Jordus's Avatar
    Posts
    73 Posts
    Global Posts
    272 Global Posts
    #24  
    If only ronlongo's posts didnt contradict theirselves.


    I wouldnt worry too much about build number differences.

    You can have very different "Versions" of an OS but still have the actual same kernel/core OS at its....welll....core.

    Think of all the different versions of, say, Windows Vista...which also shares the build number with Server 2008.
  5. #25  
    Quote Originally Posted by Jordus View Post
    If only ronlongo's posts didnt contradict theirselves.


    I wouldnt worry too much about build number differences.

    You can have very different "Versions" of an OS but still have the actual same kernel/core OS at its....welll....core.

    Think of all the different versions of, say, Windows Vista...which also shares the build number with Server 2008.
    Just FYI, WebOS Quick Install shows a little more than the average "Version: xx.xx.xx" label.
    http://img196.imageshack.us/img196/4...ckinstall2.jpg

    It's be interesting to see how the fine details differ
  6. #26  
    Quote Originally Posted by Jordus View Post
    If only ronlongo's posts didnt contradict theirselves.


    I wouldnt worry too much about build number differences.

    You can have very different "Versions" of an OS but still have the actual same kernel/core OS at its....welll....core.

    Think of all the different versions of, say, Windows Vista...which also shares the build number with Server 2008.
    Isn't that what I said? Build numbers and revision numbers are two different things neither of which has anything to do with a software version number.

    What's the contradiction you perceive?
  7. Jordus's Avatar
    Posts
    73 Posts
    Global Posts
    272 Global Posts
    #27  
    You said that software gets branched for different teams to work on different things, and then those changes get merged back into the software.

    Then you said that palm was probably doing this and would probably merge branch projects back into the core, and in the very next line said they probably wouldnt.


    Maybe you meant they are keeping the core seperate and only using the "branch" changes for different carriers, but thats not how it read.
Page 2 of 2 FirstFirst 12

Posting Permissions