|
| 1 | +# Developing locally |
| 2 | + |
| 3 | +Since Kohana maintains many concurrent versions at once, there is no single `master` branch. All versions have branches named with a prefix of its version: |
| 4 | + |
| 5 | + - 3.2/master |
| 6 | + - 3.2/develop |
| 7 | + - 3.3/master |
| 8 | + - 3.3/develop |
| 9 | + |
| 10 | +and so on. All development of versions happens in the develop branch of that version. Before a release, new features are added here. After a major release is actually released, only bugfixes can happen here. New features and API changes must happen in the develop branch of the next version. |
| 11 | + |
| 12 | +## Branch name meanings |
| 13 | + |
| 14 | + - **3.3/master** - master branches are for releases. Only release merge commits can be applied to this branch. You should never make a non-merge commit to this branch, and all merge commits should come from the release branch or hotfix branch (detailed below). This branch lasts forever. |
| 15 | + - **3.3/hotfix/*** - hotfix branches are for emergency maintenance after a release. If an important security or other kind of important issue is discovered after a release, it should be done here, and merged to master. This branch should be created from master and merged back into master and develop when complete. This branch is deleted after it's done. |
| 16 | + - **3.3/develop** - If a version is not released, this branch is for merging features into. If the version is released, this branch is for applying bugfix commits to. This branch lasts forever. |
| 17 | + - **3.3/release/*** - release branches are for maintenance work before a release. This branch should be branched from the develop branch only. Change the version number/code name here, and apply any other maintenance items needed before actually releasing. Merges from master should only come from this branch. It should be merged to develop when it's complete as well. This branch is deleted after it's done. |
| 18 | + - **3.3/feature/*** - Details on these branches are outlined below. This branch is deleted after it's done. |
| 19 | + |
| 20 | +If an bug/issue applies to multiple versions of Kohana, it is first fixed in the lowest supported version it applies to, then merged to each higher branch it applies to. Each merge should only happen one version up. 3.1 should merge to 3.2, and 3.2 should merge to 3.3. 3.1 should not merge directly to 3.3. |
| 21 | + |
| 22 | +To work on a specific release branch you need to check it out then check out the appropriate system branch. |
| 23 | +Release branch names follow the same convention in both kohana/kohana and kohana/core. |
| 24 | + |
| 25 | +To work on 3.3.x you'd do the following: |
| 26 | + |
| 27 | + > git clone git://github.com/kohana/kohana.git |
| 28 | + # .... |
| 29 | + |
| 30 | + > cd kohana |
| 31 | + > git submodule update --init |
| 32 | + # .... |
| 33 | + |
| 34 | + > git checkout 3.3/develop |
| 35 | + # Switched to branch '3.3/develop' |
| 36 | + |
| 37 | + > git submodule foreach "git fetch && git checkout 3.3/develop" |
| 38 | + # ... |
| 39 | + |
| 40 | +It's important that you follow the last step, because unlike SVN, Git submodules point at a |
| 41 | +specific commit rather than the tip of a branch. If you cd into the system folder after |
| 42 | +a `git submodule update` and run `git status` you'll be told: |
| 43 | + |
| 44 | + # Not currently on any branch. |
| 45 | + nothing to commit (working directory clean) |
| 46 | + |
| 47 | +*** |
| 48 | + |
| 49 | +# Contributing to the project |
| 50 | + |
| 51 | +All features and bugfixes must be fully tested and reference an issue in the [tracker](http://dev.kohanaframework.org/projects/kohana3), **there are absolutely no exceptions**. |
| 52 | + |
| 53 | +It's highly recommended that you write/run unit tests during development as it can help you pick up on issues early on. See the Unit Testing section below. |
| 54 | + |
| 55 | +## Creating new features |
| 56 | + |
| 57 | +New features or API breaking modifications should be developed in separate branches so as to isolate them |
| 58 | +until they're stable. |
| 59 | + |
| 60 | +**Features without tests written will be rejected! There are NO exceptions.** |
| 61 | + |
| 62 | +The naming convention for feature branches is: |
| 63 | + |
| 64 | + {version}/feature/{issue number}-{short hyphenated description} |
| 65 | + |
| 66 | + // e.g. |
| 67 | + |
| 68 | + 3.2/feature/4045-rewriting-config-system |
| 69 | + |
| 70 | +When a new feature is complete and fully tested it can be merged into its respective release branch using |
| 71 | +`git pull --no-ff`. The `--no-ff` switch is important as it tells Git to always create a commit |
| 72 | +detailing what branch you're merging from. This makes it a lot easier to analyse a feature's history. |
| 73 | + |
| 74 | +Here's a quick example: |
| 75 | + |
| 76 | + > git status |
| 77 | + # On branch 3.2/feature/4045-rewriting-everything |
| 78 | + |
| 79 | + > git checkout 3.1/develop |
| 80 | + # Switched to branch '3.1/develop' |
| 81 | + |
| 82 | + > git merge --no-ff 3.2/feature/4045-rewriting-everything |
| 83 | +
|
| 84 | +**If a change you make intentionally breaks the API then please correct the relevant tests before pushing!** |
| 85 | + |
| 86 | +## Bug fixing |
| 87 | + |
| 88 | +If you're making a bugfix then before you start create a unit test which reproduces the bug, |
| 89 | +using the `@ticket` notation in the test to reference the bug's issue number |
| 90 | +(e.g. `@ticket 4045` for issue #4045). |
| 91 | + |
| 92 | +If you run the unit tests then the one you've just made should fail. |
| 93 | + |
| 94 | +Once you've written the bugfix, run the tests again before you commit to make sure that the |
| 95 | +fix actually works, then commit both the fix and the test. |
| 96 | + |
| 97 | +**Bug fixes without tests written will be rejected! There are NO exceptions.** |
| 98 | + |
| 99 | +There is no need to create separate branches for bugfixes, creating them in the main develop |
| 100 | +branch is perfectly acceptable. |
| 101 | + |
| 102 | +## Tagging releases |
| 103 | + |
| 104 | +Tag names should be prefixed with a `v`, this helps to separate tag references from branch references in Git. |
| 105 | + |
| 106 | +For example, if you were creating a tag for the `3.1.0` release the tag name would be `v3.1.0` |
| 107 | + |
| 108 | +# Merging changes from remote repositories |
| 109 | + |
| 110 | +Now that you have a remote repository, you can pull changes in the remote "kohana" repository |
| 111 | +into your local repository: |
| 112 | + |
| 113 | + > git pull kohana 3.1/master |
| 114 | + |
| 115 | +**Note:** Before you pull changes you should make sure that any modifications you've made locally |
| 116 | +have been committed. |
| 117 | + |
| 118 | +Sometimes a commit you've made locally will conflict with one made in the remote "kohana" repo. |
| 119 | + |
| 120 | +There are a couple of scenarios where this might happen: |
| 121 | + |
| 122 | +## The conflict is due to a few unrelated commits and you want to keep changes made in both commits |
| 123 | + |
| 124 | +You'll need to manually modify the files to resolve the conflict, see the "Resolving a merge" |
| 125 | +section [in the Git SCM book](http://book.git-scm.com/3_basic_branching_and_merging.html) for more info |
| 126 | + |
| 127 | +## You've fixed something locally which someone else has already done in the remote repo |
| 128 | + |
| 129 | +The simplest way to fix this is to remove all the changes that you've made locally. |
| 130 | + |
| 131 | +You can do this using |
| 132 | + |
| 133 | + > git reset --hard kohana |
| 134 | + |
| 135 | +## You've fixed something locally which someone else has already fixed but you also have separate commits you'd like to keep |
| 136 | + |
| 137 | +If this is the case then you'll want to use a tool called rebase. First of all we need to |
| 138 | +get rid of the conflicts created due to the merge: |
| 139 | + |
| 140 | + > git reset --hard HEAD |
| 141 | + |
| 142 | +Then find the hash of the offending local commit and run: |
| 143 | + |
| 144 | + > git rebase -i {offending commit hash} |
| 145 | + |
| 146 | +i.e. |
| 147 | + |
| 148 | + > git rebase -i 57d0b28 |
| 149 | +
|
| 150 | +A text editor will open with a list of commits. Delete the line containing the offending commit |
| 151 | +before saving the file & closing your editor. |
| 152 | + |
| 153 | +Git will remove the commit and you can then pull/merge the remote changes. |
| 154 | + |
| 155 | +# Unit Testing |
| 156 | + |
| 157 | +Kohana currently uses PHPUnit for unit testing. This is installed with composer. |
| 158 | + |
| 159 | +## How to run the tests |
| 160 | + |
| 161 | + * Install [Phing](http://phing.info) |
| 162 | + * Make sure you have the [unittest](http://github.com/kohana/unittest) module enabled. |
| 163 | + * Install [Composer](http://getcomposer.org) |
| 164 | + * Run `php composer.phar install` from the root of this repository |
| 165 | + * Finally, run `phing test` |
| 166 | + |
| 167 | +This will run the unit tests for core and all the modules and tell you if anything failed. If you haven't changed anything and you get failures, please create a new issue on [the tracker](http://dev.kohanaframework.org) and paste the output (including the error) in the issue. |
0 commit comments