Changes between Version 2 and Version 3 of DRM4G/Development

Dec 7, 2016 1:26:38 PM (5 years ago)



  • DRM4G/Development

    v2 v3  
    47 == Our Git workflow ==
    49 In this section you'll find the guidelines of how we tackle the development process.
    52 == Committing changes ==
    54 After you've tested that everything is in working order it's time to update your local repository.
    56 {{{#!sh
    57 git add .
    58 git commit -m "Description of the changes you've made"
    59 git push origin <branch_name>
    60 }}}
    62 From here you'll have to create a '''Pull request'''.
     103== Our Git workflow ==
     105In this section you'll find the guidelines of how we tackle the development process.
     107As mentioned above, to us, our ''central'' repository will be a private one hosted by '''''!GitBucket''''', but in addition we have a second public one hosted in ''!GitHub'' to make the DRM4G accessible to anyone that might want to contribute to the project.
     109Both this two repositories have at least two branches, the '''master''' and the '''develop''' branches, that must be synchronized at all times.
     111Commits 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.
     113The '''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.
     118=== Getting ready for a release ===
     120Once 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.
     122From this point on, all the following changes done on this branch will be for the following release. So, to avoid halting the development of the project a new branch is created indicating the new release number.
     123* The nomenclature will be a string followed by the new version in numbers in the form of '''__DRM4G-MAJOR.MINOR.PATCH__''' and will have its number increment following this guidelines:
     124 *   '''MAJOR''' version when you add some new functionality or you make incompatible API changes,
     125 *   '''MINOR''' version when you improve some part of the DRM4G's functionality in a backwards-compatible manner
     126 *   '''PATCH''' version when you make backwards-compatible bug fixes.
     127* For creating '''tags''', the same naming convention will be followed, albeit just the digits will be used.
     129It 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.
     130* 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.
     132When ready, all that needs to be done is merge it into the '''master''', create a tag, update the remote repositories and [wiki:DRM4G/Development#Publishingarelease publish the new release].
     135git checkout master
     136git merge --squash DRM4G-X.X.X
     137git tag X.X.X
     138git commit -v
     139git push origin master
     140git push origin --tags
     141git push github master
     142git push github --tags
     144* When performing the commit, the commit message will include all the previous commits made, but at the beginning a detailed message describing what is being added should be included.
     145* 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 use to easily see the changes made between commits.
     147Updating 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''.
    119153== Publishing a release ==
    121 After having updated the "master", it's time to publish the release.
     155After having updated the '''master''', it's time to publish the release.
    1221561. First, the package has to be uploaded to PyPI, there's a few ways to do this, but you'll need to have an account with access to the groups PyPI page.
    123157 * Run the command `python sdist upload` [[br]] ''or''