Changes between Version 33 and Version 34 of DRM4G/Development
- Timestamp:
- Feb 17, 2021 12:15:22 PM (15 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DRM4G/Development
v33 v34 220 220 git fetch 221 221 git checkout master #to create a local repository of the master branch 222 git checkout devel op #to create a local repository of the developbranch222 git checkout devel #to create a local repository of the devel branch 223 223 }}} 224 224 ^If you want to see the changes your doing, check the file "'''__.git/config__'''" under your repository directory.^ … … 265 265 [[br]] 266 266 267 Both this repositories have at least two branches, the '''master''' and the '''devel op''' branches.267 Both this repositories have at least two branches, the '''master''' and the '''devel''' branches. 268 268 * 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. 269 269 270 * The '''devel op''' 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. 271 271 272 272 ---- … … 313 313 === Adding new features === 314 314 315 Each time __some big change__ or __new feature__ is going to be implemented, a new '''__feature branch__''' has to be created from the '''devel op''' branch.315 Each time __some big change__ or __new feature__ is going to be implemented, a new '''__feature branch__''' has to be created from the '''devel''' branch. 316 316 317 317 The '''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. … … 321 321 322 322 {{{#!sh 323 git checkout devel op323 git checkout devel 324 324 git checkout -b new_feature #it will switch you to the new branch 325 325 }}} 326 326 327 When finished, the branch __has to be [=#mergeIntoDevelop merged back into the '''devel op''' branch__]. After it can be deleted.328 * To keep the log history of the branches created, the merges to the '''devel op''' 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 '''devel op''' 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 devel op327 When 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 331 Before 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 335 git checkout devel 336 336 git merge --no-ff new_feature 337 337 git branch -d new_feature 338 git push origin devel op339 }}} 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 '''devel op''':338 git push origin devel 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 '''devel''': 342 342 343 343 {{{#!sh … … 353 353 [[br]] 354 354 === 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 '''devel op''' branch, the merges will be fast forwarded.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 '''devel''' branch, the merges will be fast forwarded. 356 356 {{{#!sh 357 357 git checkout branch_a … … 363 363 === Getting ready for a release === 364 364 365 Once all the new changes for the next release have been added to the '''devel op''' 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 '''devel op''' 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.365 Once 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 367 From 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. 368 368 * 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: 369 369 * '''MAJOR''' version when you add some new functionality or you make incompatible API changes … … 374 374 __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. 375 375 * 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 '''devel op''' 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. 377 377 378 378 When 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]. … … 388 388 * 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. 389 389 390 Updating the '''devel op''' 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 devel op390 Updating 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 393 git checkout devel 394 394 git merge --no-ff drm4g-X.X.X 395 git push origin devel op395 git push origin devel 396 396 }}} 397 397 … … 423 423 424 424 As 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 '''devel op''' branch.425 * This is done like this as to not disrupt the teams working on the '''devel''' branch. 426 426 * The nomenclature followed would be '''__hotfix-MAJOR.MINOR.PATCH__''' 427 427 * The version number would only have to bump up by one the '''PATCH''' version. … … 429 429 430 430 After 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 '''devel op''' 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. 432 432 433 433 If 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.
