Changes between Version 33 and Version 34 of DRM4G/Development


Ignore:
Timestamp:
Feb 17, 2021 12:15:22 PM (15 months ago)
Author:
antonio
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DRM4G/Development

    v33 v34  
    220220git fetch
    221221git checkout master #to create a local repository of the master branch
    222 git checkout develop #to create a local repository of the develop branch
     222git checkout devel #to create a local repository of the devel branch
    223223}}}
    224224 ^If you want to see the changes your doing, check the file "'''__.git/config__'''" under your repository directory.^
     
    265265[[br]]
    266266
    267 Both this repositories have at least two branches, the '''master''' and the '''develop''' branches.
     267Both this repositories have at least two branches, the '''master''' and the '''devel''' branches.
    268268* Commits in the '''master''' branch represent all the stable versions of the DRM4G. This means that merges to this branch are only done when ready to publish a release.
    269269
    270 * The '''develop''' branch reflects the whole evolution of the project. It shows all of the new features and bug fixes that have been included. This is the main branch where all of the work will be done.
     270* The '''devel''' branch reflects the whole evolution of the project. It shows all of the new features and bug fixes that have been included. This is the main branch where all of the work will be done.
    271271
    272272----
     
    313313=== Adding new features ===
    314314
    315 Each time __some big change__ or __new feature__ is going to be implemented, a new '''__feature branch__''' has to be created from the '''develop''' branch.
     315Each time __some big change__ or __new feature__ is going to be implemented, a new '''__feature branch__''' has to be created from the '''devel''' branch.
    316316
    317317The '''feature branches''' are how new functionalities are introduced and [wiki:DRM4G/Development#TestingtheDRM4G tested]. Normally the finalization of one of them will also define when a new release will be published, but that's not always the case since a new release may include more than one new feature.
     
    321321
    322322{{{#!sh
    323 git checkout develop
     323git checkout devel
    324324git checkout -b new_feature #it will switch you to the new branch
    325325}}}
    326326
    327 When finished, the branch __has to be [=#mergeIntoDevelop merged back into the '''develop''' branch__]. After it can be deleted.
    328 * To keep the log history of the branches created, the merges to the '''develop''' branch, will always be done with the no fast-forward option "'''--no-ff'''".
    329 
    330 {{{#!comment
    331 Before merging, maybe it would be advisable to merge the '''develop''' branch into the '''feature branch''', to resolve any possible conflicts and to verify that all the changes work properly, at least in the case where further changes have been done to the '''develop''' since the '''feature branch''' was created. Then if everything goes well merge the '''feature branch''' into the '''develop''' branch.
    332 }}}
    333 
    334 {{{#!sh
    335 git checkout develop
     327When finished, the branch __has to be [=#mergeIntoDevelop merged back into the '''devel''' branch__]. After it can be deleted.
     328* To keep the log history of the branches created, the merges to the '''devel''' branch, will always be done with the no fast-forward option "'''--no-ff'''".
     329
     330{{{#!comment
     331Before merging, maybe it would be advisable to merge the '''devel''' branch into the '''feature branch''', to resolve any possible conflicts and to verify that all the changes work properly, at least in the case where further changes have been done to the '''devel''' since the '''feature branch''' was created. Then if everything goes well merge the '''feature branch''' into the '''devel''' branch.
     332}}}
     333
     334{{{#!sh
     335git checkout devel
    336336git merge --no-ff new_feature
    337337git branch -d new_feature
    338 git push origin develop
    339 }}}
    340 
    341 To make the log more readable, in the cases in which a lot of small commits were made in the '''feature branch''', it may be advisable to ''rebase'' to merge some commits before doing the merge into '''develop''':
     338git push origin devel
     339}}}
     340
     341To make the log more readable, in the cases in which a lot of small commits were made in the '''feature branch''', it may be advisable to ''rebase'' to merge some commits before doing the merge into '''devel''':
    342342
    343343{{{#!sh
     
    353353[[br]]
    354354=== Updating a branch ===
    355 Sometimes you'll want to __incorporate the changes or improvements__ made in __one branch into another one__. To avoid making the log history too complicated when merging the '''feature branch''' back into the '''develop''' branch, the merges will be fast forwarded.
     355Sometimes you'll want to __incorporate the changes or improvements__ made in __one branch into another one__. To avoid making the log history too complicated when merging the '''feature branch''' back into the '''devel''' branch, the merges will be fast forwarded.
    356356{{{#!sh
    357357git checkout branch_a
     
    363363=== Getting ready for a release ===
    364364
    365 Once all the new changes for the next release have been added to the '''develop''' branch and it is at a stable point, it's time to publish a new release.
    366 
    367 From this point on, all the following changes done on the '''develop''' branch will be for the following release. So, to avoid halting the development of the project a new '''__release branch__''' is created indicating the new release number.
     365Once all the new changes for the next release have been added to the '''devel''' branch and it is at a stable point, it's time to publish a new release.
     366
     367From this point on, all the following changes done on the '''devel''' branch will be for the following release. So, to avoid halting the development of the project a new '''__release branch__''' is created indicating the new release number.
    368368* The nomenclature for all '''release branches''' will be a string followed by the new version in numbers in the form of '''__drm4g-MAJOR.MINOR.PATCH__''' and they will have their numbers increase following these guidelines:
    369369 *   '''MAJOR''' version when you add some new functionality or you make incompatible API changes
     
    374374__It is in this branch where the version number of all the files will be modified__, and where the code will be brought to a release ready state. That means that it is where minor bug fixes will be made, where comments and unnecessary code snippets will be removed and other maintenance tasks will be carried out.
    375375* You should verify that the files "__drm4g/!__init!__.py__" and the "__setup.py__" and all of the files in "__drm4g/bin__" have their versions udated.
    376 * During this process you might want to merge the new version number or some of the bug fixes on to the '''develop''' branch so that future features may incorporate them.
     376* During this process you might want to merge the new version number or some of the bug fixes on to the '''devel''' branch so that future features may incorporate them.
    377377
    378378When ready, all that needs to be done is [=#mergeIntoMaster merge it into the '''master'''], create a tag, update the remote repository and [wiki:DRM4G/Development#Publishingarelease publish the new release].
     
    388388* Squashing all the commits when doing the merge, will ensure that every commit in the master is a stable version and will make the log history cleaner, allowing us to easily see the changes made between commits.
    389389
    390 Updating the '''develop''' will be a bit different.  If it is ever needed to rollback to a previous version, its commit has to be accessible. So merges to the '''develop''' branch ''__won't be squashed__''.
    391 
    392 {{{#!sh
    393 git checkout develop
     390Updating the '''devel''' will be a bit different.  If it is ever needed to rollback to a previous version, its commit has to be accessible. So merges to the '''devel''' branch ''__won't be squashed__''.
     391
     392{{{#!sh
     393git checkout devel
    394394git merge --no-ff drm4g-X.X.X
    395 git push origin develop
     395git push origin devel
    396396}}}
    397397
     
    423423
    424424As an exception to the normal flow of the development, in the cases when an important error is discovered only after the release has been published, a '''__hotfix branch__''' can be created from the '''master''' to fix it.
    425  * This is done like this as to not disrupt the teams working on the '''develop''' branch.
     425 * This is done like this as to not disrupt the teams working on the '''devel''' branch.
    426426 * The nomenclature followed would be '''__hotfix-MAJOR.MINOR.PATCH__'''
    427427  * The version number would only have to bump up by one the '''PATCH''' version.
     
    429429
    430430After the problem was solved, you'd have to follow the instructions [wiki:DRM4G/Development#Gettingreadyforarelease to prepare for a new release], except considering the '''hotfix branch''' to be the '''release branch'''.
    431 * That means that a new release branch shouldn't be created. But this branch would have to be merged back into the '''master''' and the '''develop''' branch following the instructions set in the previous section.
     431* That means that a new release branch shouldn't be created. But this branch would have to be merged back into the '''master''' and the '''devel''' branch following the instructions set in the previous section.
    432432
    433433If it turns out to be a __critical error__ and not something fixable in a few hours, __the release would have to be retracted__ until the issue got resolved.