From c0471d65c8100aef6b5478ebbf2f381eaab39b55 Mon Sep 17 00:00:00 2001 From: BRMatt Date: Sun, 18 Jul 2010 00:10:42 +0100 Subject: [PATCH 1/9] Updating system --- system | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system b/system index 3e1ab62..a89a7a4 160000 --- a/system +++ b/system @@ -1 +1 @@ -Subproject commit 3e1ab624c929d31b678653d335de1918c9061226 +Subproject commit a89a7a4149ba25359e4f6f025cc08772a9241d7a From 24492ffad8a7af49869d06047eebb07b1ec51a39 Mon Sep 17 00:00:00 2001 From: BRMatt Date: Sun, 18 Jul 2010 00:34:31 +0100 Subject: [PATCH 2/9] Adding release script --- .gitignore | 1 + release-tag | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) create mode 100755 release-tag diff --git a/.gitignore b/.gitignore index d475fd1..01d3056 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,4 @@ code_coverage *~ *.swp coverage +kohana_release diff --git a/release-tag b/release-tag new file mode 100755 index 0000000..8d65dd4 --- /dev/null +++ b/release-tag @@ -0,0 +1,72 @@ +#!/bin/bash +# This script deploys kohana to zip / tar / gzip format & removes development extras +# It expects a valid git tag as the first parameter + +DEPLOY_DIR="kohana_release" +TESTING_FILES="application/test_bootstrap.php phpunit.xml code_coverage.xml phpunitcc TESTING.md" +KOHANA_REPO="git://github.com/kohana/kohana" +USAGE="\nUsage: $0 {git-tag} +\nWhere {git-tag} is a valid tag in the git repository" + +# A tag must be provided as the first argument +if [ -z $1 ]; then + echo "$0 - A small script to prepare a kohana tag for relase." + echo "If unit tests complete it removes testing files and archives the codebase" + echo -e $USAGE + exit 1 +fi + +# Just setting this lest we need to refactor later on +DEPLOY_TAG=$1 + +# Bit of a hacky way to find if a tag exists +git tag -l $DEPLOY_TAG | grep -E ".+" &> /dev/null + +# Check that the exit code of grep was 0 (i.e. it matched something 1+ times) +if [ $? -ne 0 ]; then + echo "Could not find specified tag in git repo ($DEPLOY_TAG)" + echo -e $USAGE + exit 2 +fi + +echo "Creating a clean deploy environment called '$DEPLOY_DIR'..." + +# Create a clean temp area to deploy our stuff +rm -rf $DEPLOY_DIR +mkdir $DEPLOY_DIR +cd $DEPLOY_DIR + +echo "Cloning the repo and checking out the tag to deploy..." +# Bring down a fresh copy of the kohana repo +git clone $KOHANA_REPO repo +cd repo + +# Checkout the tag we want to deploy and fetch all the submodules +git checkout --quiet $DEPLOY_TAG +git submodule update --init + +echo "Running tests to ensure release is stable..." +phpunit + +# We cannot release something that's not stable +if [ $? -ne 0 ]; then + echo "Some unit tests did not pass, exiting release" + exit 3 +fi + +echo "Removing testing files..." + +# Now we remove all unit testing files +rm -vrf $TESTING_FILES + +# Including any tests across all modules +find . -type d -regex ".*/tests$" | xargs rm -vrf + +# And now we package the whole thing up in archive form +echo "Packaging repo into zip and tar.gz archives..." + +zip -r -q $DEPLOY_TAG.zip * +mv $DEPLOY_TAG.zip ../ + +tar -czf $DEPLOY_TAG.tar.gz * +mv $DEPLOY_TAG.tar.gz ../ From 6b1e4fa00e9fb01c34dc5039e9d7752e6dfcf21e Mon Sep 17 00:00:00 2001 From: BRMatt Date: Sun, 18 Jul 2010 22:53:51 +0100 Subject: [PATCH 3/9] Quick fix to release tag & added a todo to testing docs --- TESTING.md | 6 ++++++ release-tag | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/TESTING.md b/TESTING.md index 019104e..ffb17e6 100644 --- a/TESTING.md +++ b/TESTING.md @@ -22,6 +22,12 @@ By default code coverage is not calculated, if you want to collect it then you n run phpunit with the config in `code_coverage.xml`. Once the tests have finished running open `code_coverage/index.html` in your browser. +Things to Test (TODO) +--- + +* Need extra tests for Validate to make sure filters(), rules(), callbacks() will convert the field name to a label if a label + does not exist + Known failing tests --- diff --git a/release-tag b/release-tag index 8d65dd4..d01bf24 100755 --- a/release-tag +++ b/release-tag @@ -3,7 +3,7 @@ # It expects a valid git tag as the first parameter DEPLOY_DIR="kohana_release" -TESTING_FILES="application/test_bootstrap.php phpunit.xml code_coverage.xml phpunitcc TESTING.md" +TESTING_FILES="application/test_bootstrap.php phpunit.xml code_coverage.xml phpunitcc TESTING.md release-tag" KOHANA_REPO="git://github.com/kohana/kohana" USAGE="\nUsage: $0 {git-tag} \nWhere {git-tag} is a valid tag in the git repository" From abbffd5b284dbf6be648e0525182ea51fba3a013 Mon Sep 17 00:00:00 2001 From: BRMatt Date: Sun, 25 Jul 2010 19:03:19 +0100 Subject: [PATCH 4/9] Updating DEVELOPERS.md, fixes #3114 --- DEVELOPERS.md | 83 +++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 67 insertions(+), 16 deletions(-) diff --git a/DEVELOPERS.md b/DEVELOPERS.md index 79585d6..11a9c84 100644 --- a/DEVELOPERS.md +++ b/DEVELOPERS.md @@ -14,35 +14,86 @@ Please read the following before working with this code: First, you will need to tell git about the remote repository: - git remote add kohana git://github.com/kohana/kohana.git + > git remote add kohana git://github.com/kohana/kohana.git -This adds "kohana" as a remote repository that can be pulled from. +This tells git about the kohana repository and gives it a name which we can use to refer to it when fetching changes from the repository. - git checkout -b kohana/master +## Developing locally -This creates a local branch "kohana/master" of the master branch of the "kohana" repository. +There are 3 branches in the kohana/kohana repository: + +* **master** This branch always points to the latest release tag. In essence it points to the last stable edition of the codebase +* **3.0.x** This is a release branch for development of the 3.0.x series, i.e. 3.0, 3.0.3, 3.0.8 etc. +* **3.1.x** This is a release branch for development of the 3.1.x series, i.e. 3.1, 3.1.4, 3.1.14 etc. + +To work on a specific release branch you need to check it out then check out the appropriate system branch (the system repo uses 3.0 and 3.1 instead of 3.0.x and 3.1.x). + +i.e. to work on 3.0.x you'd do the following + + > git checkout 3.0.x + Switched to branch '3.0.x' + + > cd system + > git checkout 3.0 + Switched to branch 3.0 + +**Note:** The last step is necessary due to the way that git submodules work. + +It is highly recommended that you run the unit tests while developing to ensure that any changes you make don't break the api. *See TESTING.md for more info* + +### Creating new features + +New features or API breaking modifications should be developed in separate branches so as to isolate them until they're both stable and **fully tests have been written**. +When a new feature is complete and tested it can be merged into its respective release branch. + +If a change you make intentionally breaks the api then please correct the relevant tests. + +### Bug fixing + +If you're making a bugfix then before you start create a unit test which reproduces the bug, using the @ticket notation to reference the bug's ticket number. When you run the tests then this test should fail. + +Once you've written the bugfix run the tests again before you commit to make sure that the fix actually works, then commit the fix and the test. + +There is no need to create separate branches for bugfixes, creating them in the main release branch is perfectly acceptable. ## Merging Changes from Remote Repositories -Now that you have a remote repository, you can pull changes into your local repository: +Now that you have a remote repository, you can pull changes in the remote "kohana" repository into your local repository: - git checkout kohana/master + > git pull kohana master -This switches to the previously created "kohana/master" branch. +**Note:** Before you pull changes you should make sure that any modifications you've made locally have been committed - git pull kohana master +Sometimes a commit you've made locally will conflict with one made in the "kohana" one. -This pulls all of the changes from the remote into the local "kohana/master" branch. +There are a couple of scenarios where this might happen: - git checkout master +### The conflict is to do with a few unrelated commits and you want to keep changes made in both commits -This switches back to your local master branch. +You'll need to manually modify the files to resolve the conflict, see the "Resolving a merge" section [in the git-scm book](http://book.git-scm.com/3_basic_branching_and_merging.html) for more info - git merge kohana/master +### You've fixed something locally which someone else has already done in the remote repo -This merges all of the changes in the "kohana/master" branch into your master branch. +The simplest way to fix this is to remove all the changes that you've made locally. - git push +You can do this using -This pushes all the merged changes into your local fork. At this point, your fork is now in sync -with the origin repository! \ No newline at end of file + > git reset --hard kohana + +### You've fixed something locally which someone else has already fixed but you also have separate commits you'd like to keep + +If this is the case then you'll want to use a tool called rebase. First of all we need to get rid of the conflicts created due to the merge: + + > git reset --hard HEAD + +Then we find the hash of the offending local commit and run: + + > git rebase -i {commit hash} + +i.e. + + > git rebase -i 57d0b28 + +A text editor will open with a list of commits, delete the line containing the offending commit and then save & close your editor. + +Git will remove the commit and you can then pull/merge the remote changes. From dbf5603ef7ed5837195ca733c3b638aec8fcd904 Mon Sep 17 00:00:00 2001 From: BRMatt Date: Sun, 25 Jul 2010 19:07:56 +0100 Subject: [PATCH 5/9] Fixing spelling mistake --- DEVELOPERS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DEVELOPERS.md b/DEVELOPERS.md index 11a9c84..bbda2c0 100644 --- a/DEVELOPERS.md +++ b/DEVELOPERS.md @@ -43,7 +43,7 @@ It is highly recommended that you run the unit tests while developing to ensure ### Creating new features -New features or API breaking modifications should be developed in separate branches so as to isolate them until they're both stable and **fully tests have been written**. +New features or API breaking modifications should be developed in separate branches so as to isolate them until they're both stable and **tests have been written for the feature**. When a new feature is complete and tested it can be merged into its respective release branch. If a change you make intentionally breaks the api then please correct the relevant tests. From c69741646f6b930e65dfe2c0ee6d16e1918e7434 Mon Sep 17 00:00:00 2001 From: Kiall Mac Innes Date: Tue, 27 Jul 2010 18:17:30 +0100 Subject: [PATCH 6/9] Updated system submodule. --- system | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system b/system index a89a7a4..31e1000 160000 --- a/system +++ b/system @@ -1 +1 @@ -Subproject commit a89a7a4149ba25359e4f6f025cc08772a9241d7a +Subproject commit 31e10004919f305533c194e2df8104a9bd1709cc From 1aef83b118515b7e2f9055e9d621f2f1365b0da5 Mon Sep 17 00:00:00 2001 From: BRMatt Date: Thu, 29 Jul 2010 19:43:12 +0100 Subject: [PATCH 7/9] Added a bit more info inc. stuff about --no-ff --- DEVELOPERS.md | 90 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 69 insertions(+), 21 deletions(-) diff --git a/DEVELOPERS.md b/DEVELOPERS.md index bbda2c0..c157592 100644 --- a/DEVELOPERS.md +++ b/DEVELOPERS.md @@ -16,7 +16,8 @@ First, you will need to tell git about the remote repository: > git remote add kohana git://github.com/kohana/kohana.git -This tells git about the kohana repository and gives it a name which we can use to refer to it when fetching changes from the repository. +This tells git about the kohana repository and gives it a name which we can use to refer to it when +fetching changes from the repository. ## Developing locally @@ -26,43 +27,87 @@ There are 3 branches in the kohana/kohana repository: * **3.0.x** This is a release branch for development of the 3.0.x series, i.e. 3.0, 3.0.3, 3.0.8 etc. * **3.1.x** This is a release branch for development of the 3.1.x series, i.e. 3.1, 3.1.4, 3.1.14 etc. -To work on a specific release branch you need to check it out then check out the appropriate system branch (the system repo uses 3.0 and 3.1 instead of 3.0.x and 3.1.x). +To work on a specific release branch you need to check it out then check out the appropriate system branch. +Release branch names follow the same convention in both kohana/kohana and kohana/core. -i.e. to work on 3.0.x you'd do the following +To work on 3.0.x you'd do the following: + + > git clone git://github.com/kohana/kohana.git + # .... + + > cd kohana + > git submodule update --init + # .... > git checkout 3.0.x - Switched to branch '3.0.x' + # Switched to branch '3.0.x' > cd system - > git checkout 3.0 - Switched to branch 3.0 + > git checkout 3.0.x + # Switched to branch 3.0.x -**Note:** The last step is necessary due to the way that git submodules work. +It's important that you follow the last step, because unlike svn, git submodules point at a +specific commit rather than the tip of a branch. If you cd into the system folder after +a `git submodule update` and run `git status` you'll be told: -It is highly recommended that you run the unit tests while developing to ensure that any changes you make don't break the api. *See TESTING.md for more info* + # Not currently on any branch. + nothing to commit (working directory clean) + +**IMPORTANT:** It is highly recommended that you run the unit tests whilst developing to +ensure that any changes you make do not break the api. *See TESTING.md for more info* ### Creating new features -New features or API breaking modifications should be developed in separate branches so as to isolate them until they're both stable and **tests have been written for the feature**. -When a new feature is complete and tested it can be merged into its respective release branch. +New features or API breaking modifications should be developed in separate branches so as to isolate them +until they're stable and **tests have been written for the feature**. -If a change you make intentionally breaks the api then please correct the relevant tests. +The naming convention for feature branches is: + + feature/{issue number}-{short hyphenated description} + + // i.e. + + feature/4045-rewriting-config-system + +When a new feature is complete and tested it can be merged into its respective release branch using +`git pull --no-ff`. The `--no-ff` switch is important as it tells git to always create a commit +detailing what branch you're merging from. This makes it a lot easier to analyse a feature's history. + +Here's a quick example: + + > git status + # On branch feature/4045-rewriting-everything + + > git checkout 3.1.x + # Switched to branch '3.1.x' + + > git merge --no-ff feature/4045-rewriting-everything + +**If a change you make intentionally breaks the api then please correct the relevant tests before pushing!** ### Bug fixing -If you're making a bugfix then before you start create a unit test which reproduces the bug, using the @ticket notation to reference the bug's ticket number. When you run the tests then this test should fail. +If you're making a bugfix then before you start create a unit test which reproduces the bug, +using the `@ticket` notation in the test to reference the bug's issue number +(i.e. `@ticket 4045` for issue #4045). -Once you've written the bugfix run the tests again before you commit to make sure that the fix actually works, then commit the fix and the test. +If you run the test then the one you've just made should fail. -There is no need to create separate branches for bugfixes, creating them in the main release branch is perfectly acceptable. +Once you've written the bugfix, run the tests again before you commit to make sure that the +fix actually works,then commiti both the fix and the test. + +There is no need to create separate branches for bugfixes, creating them in the main release +branch is perfectly acceptable. ## Merging Changes from Remote Repositories -Now that you have a remote repository, you can pull changes in the remote "kohana" repository into your local repository: +Now that you have a remote repository, you can pull changes in the remote "kohana" repository +into your local repository: > git pull kohana master -**Note:** Before you pull changes you should make sure that any modifications you've made locally have been committed +**Note:** Before you pull changes you should make sure that any modifications you've made locally +have been committed. Sometimes a commit you've made locally will conflict with one made in the "kohana" one. @@ -70,7 +115,8 @@ There are a couple of scenarios where this might happen: ### The conflict is to do with a few unrelated commits and you want to keep changes made in both commits -You'll need to manually modify the files to resolve the conflict, see the "Resolving a merge" section [in the git-scm book](http://book.git-scm.com/3_basic_branching_and_merging.html) for more info +You'll need to manually modify the files to resolve the conflict, see the "Resolving a merge" +section [in the git-scm book](http://book.git-scm.com/3_basic_branching_and_merging.html) for more info ### You've fixed something locally which someone else has already done in the remote repo @@ -82,18 +128,20 @@ You can do this using ### You've fixed something locally which someone else has already fixed but you also have separate commits you'd like to keep -If this is the case then you'll want to use a tool called rebase. First of all we need to get rid of the conflicts created due to the merge: +If this is the case then you'll want to use a tool called rebase. First of all we need to +get rid of the conflicts created due to the merge: > git reset --hard HEAD -Then we find the hash of the offending local commit and run: +Then find the hash of the offending local commit and run: - > git rebase -i {commit hash} + > git rebase -i {offending commit hash} i.e. > git rebase -i 57d0b28 -A text editor will open with a list of commits, delete the line containing the offending commit and then save & close your editor. +A text editor will open with a list of commits, delete the line containing the offending commit +before saving the file & closing your editor. Git will remove the commit and you can then pull/merge the remote changes. From d1267eec48c83f642ef9c0538f1bc2b1d7c6d830 Mon Sep 17 00:00:00 2001 From: Kiall Mac Innes Date: Fri, 30 Jul 2010 19:22:53 +0100 Subject: [PATCH 8/9] Updaing system submodule. --- system | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system b/system index 31e1000..3f592b7 160000 --- a/system +++ b/system @@ -1 +1 @@ -Subproject commit 31e10004919f305533c194e2df8104a9bd1709cc +Subproject commit 3f592b72c5512e626bdf7f49d7f4d89379493b10 From 9eeadee1bb5f19965ff4a6b896fe91169a40baf9 Mon Sep 17 00:00:00 2001 From: Kiall Mac Innes Date: Fri, 30 Jul 2010 19:24:41 +0100 Subject: [PATCH 9/9] Adding cache, unittest, and oauth submodules to .gitmodules-dev --- .gitmodules-dev | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/.gitmodules-dev b/.gitmodules-dev index bb3a143..f323855 100644 --- a/.gitmodules-dev +++ b/.gitmodules-dev @@ -22,3 +22,14 @@ [submodule "modules/userguide"] path = modules/userguide url = git@github.com:kohana/userguide.git +[submodule "modules/cache"] + path = modules/cache + url = git@github.com:kohana/cache.git +[submodule "modules/unittest"] + path = modules/unittest + url = git@github.com:kohana/unittest.git +[submodule "modules/oauth"] + path = modules/oauth + url = git@github.com:kohana/oauth.git + +