Changes between Version 2 and Version 3 of DRM4G/Development


Ignore:
Timestamp:
Dec 7, 2016 1:26:38 PM (5 years ago)
Author:
minondoa
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DRM4G/Development

    v2 v3  
    4444}}}
    4545
    46 
    47 == Our Git workflow ==
    48 
    49 In this section you'll find the guidelines of how we tackle the development process.
    50 
    51 
    52 == Committing changes ==
    53 
    54 After you've tested that everything is in working order it's time to update your local repository.
    55 
    56 {{{#!sh
    57 git add .
    58 git commit -m "Description of the changes you've made"
    59 git push origin <branch_name>
    60 }}}
    61 
    62 From here you'll have to create a '''Pull request'''.
    6346
    6447
     
    117100
    118101
     102
     103== Our Git workflow ==
     104
     105In this section you'll find the guidelines of how we tackle the development process.
     106
     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.
     108
     109Both this two repositories have at least two branches, the '''master''' and the '''develop''' branches, that must be synchronized at all times.
     110
     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.
     112
     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.
     114
     115
     116
     117
     118=== Getting ready for a release ===
     119
     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.
     121
     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.
     128
     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.
     131
     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].
     133
     134{{{#!sh
     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
     143}}}
     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.
     146
     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''.
     148
     149
     150
     151[[br]]
     152
    119153== Publishing a release ==
    120154
    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 setup.py sdist upload` [[br]] ''or''