Changes between Version 2 and Version 3 of SourceControlPolicy


Ignore:
Timestamp:
Oct 31, 2014 1:55:17 PM (8 years ago)
Author:
scuric
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SourceControlPolicy

    v2 v3  
    2323======================
    2424
    25         MASTER
     25        MASTER[[BR]]
     26
    2627        The most recent official stable DETER sources. (A link to the most recent release branch??? What is the semantics of this branch now??? -- tvf)
    2728        This should be obsoleted by Release branches. It should be renamed to release 0.93.
    2829
    29         DEVELOPMENT
     30        DEVELOPMENT[[BR]]
     31
    3032        This is the main trunk containing current development sources.
    3133        It is integration and collection branch. No support will be provided for snapshots of this branch. Anybody installing deter software or doing development is expected to take snapshots of the latest Release branch.
     
    3335        No change can be committed into this branch prior to OPS group approval, completed documentation and prior testing.
    3436
    35         RELEASE
     37        '''RELEASE'''[[BR]]
     38
    3639        A released version, known to be a valid starting point for collaborators.
    3740        Release versions are only updated to fix urgent bugs or security problems reviewed by the operations group.
    38         These are labelled by version number. The current Release is 0.93 a.k.a. MASTER.
     41        These are labelled by version number. The current Release is 0.93 a.k.a. MASTER.[[BR]]
     42
    3943        A new Release Branch will be created as snapshot of a stable (tested) DEV trunk whenever OPS group decide to release new project(s), or periodically a number of bug fixes.
    4044        This newly released branch will be then tested, updates may be applied to fix any problems. When finalized, changes will be merged back into DEV, and the new release will be announced.
    41         Problems within these branches will be fixed as minor revisions of the branch in question.
     45        Problems within these branches will be fixed as minor revisions of the branch in question.[[BR]]
     46
    4247        Release branches may periodically merged back into the Dev trunk, to pickup fixes done to that branch.
    4348        The release branches will also be under OPS group control.
    44         We should support only one or two versions back from latest release. TBD.
     49        We should support only one or two versions back from latest release. TBD.[[BR]]
     50
    4551        Procedure for creating new release should be:
    4652               1. take a snapshot of the dev branch, create new release branch
     
    4955               4. declare victory
    5056
    51         PRIVAT
     57        '''PRIVAT'''[[BR]]
     58
    5259        Developers may also create nonce branches to carry out development tasks, performance evaluations, or other common tasks.
    5360        These branches are not supported by the OPS group.
    54         The only play ground for developers and partners (to carry out development tasks, performance evaluations, bug fixing or other) is inside these branches.
     61        The only play ground for developers and partners (to carry out development tasks, performance evaluations, bug fixing or other) is inside these branches. [[BR]]
     62
    5563        They are created and deleted as required with an assigned owner.
    56         Only the owner (or member of the owner's team) of such branch can commit to it.
     64        Only the owner (or member of the owner's team) of such branch can commit to it.[[BR]]
     65
    5766        Committing changes from ISI owned branches back to the Dev Trunk can only be done by prior OPS group approval, after all paper work detailing changes and testing performed is completed.
    58         Committing changes from NON-ISI owned branches back to the Dev Trunk can only be done ISI team, upon request ,after detailed review and after OPS group approval.
     67        Committing changes from NON-ISI owned branches back to the Dev Trunk can only be done ISI team, upon request ,after detailed review and after OPS group approval.[[BR]]
     68
    5969        Procedure to prepare these branches for checkin should be
    6070               1. pull all changes from DEV branch
     
    6373               4. If ISI branch push the changes to dev, if not then OPS group will handle ...
    6474
    65         Keeping Track fixes and features in various branches
     75        '''Keeping track of fixes and features in various branches[[BR]]'''
     76
    6677        A better release control will have to be created to track what was fixed in each of the branches.
    67         As a bare minimum fixes would need to be tracked against release versions along with what and how they were tested.
     78        As a bare minimum fixes would need to be tracked against release versions along with what and how they were tested.[[BR]]
     79
    6880        Again, we should only support few branches and obsolete older ones.
    6981
    70         Definition of "accepted" change or satisfactory testing
    71         This is the criteria to declare a successful fix, new release readiness or project completion.
    72         Need to define a default, minimum or required test hardware and/or procedure. Do we really test in production environment ? How would partners do that ?
     82        '''Definition of "accepted" change or satisfactory testing'''''''''[[BR]]
     83
     84        This is the criteria to declare a successful fix, new release readiness or project completion. Required to be satisfied before checking into DEV branch can be allowed.
     85        Need to define a default, minimum or required test hardware and/or procedure.
     86        A separate mini deter hardware setup will be installed at ISI to provide for testing.
     87        How would partners do that ?
    7388        Suggestions?
    7489
    75         Tagging:
    76         Every major and/or minor release will be tagged to allow going back. The major/minor number will be a part of each version of the released software.
     90        '''Tagging:[[BR]]'''
     91
     92        Every major and/or minor release will be tagged in the DEV branch. [[BR]]
     93
     94        The major/minor number will be a part of each version of the released software.
    7795       
    7896