improved readme, contributing and license

CONTRIBUTING.md

@@ -1,60 +1,19 @@
 # Developing locally
 
-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:
+Clone the repo and develop on the Master branch. Each release will have its own Tag.
 
- - 3.2/master
- - 3.2/develop
- - 3.3/master
- - 3.3/develop
+I know its simple but for now will work ;)
 
-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.
-
-## Branch name meanings
-
- - **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.
- - **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.
- - **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.
- - **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.
- - **3.3/feature/*** - Details on these branches are outlined below. This branch is deleted after it's done.
-
-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.
-
-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.
-
-To work on 3.3.x you'd do the following:
-
-  > git clone git://github.com/kohana/kohana.git
-  # ....
-  
-  > cd kohana
-  > git submodule update --init
-  # ....
-
-  > git checkout 3.3/develop
-  # Switched to branch '3.3/develop'
-  
-  > git submodule foreach "git fetch && git checkout 3.3/develop"
-        # ...
-
-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:
-
-  # Not currently on any branch.
-  nothing to commit (working directory clean)
-
-***
 
 # Contributing to the project
 
-All features and bugfixes must be fully tested and reference an issue in  [GitHub](https://github.com/kohana/kohana/issues), **there are absolutely no exceptions**.
+All features and bugfixes must be fully tested and reference an issue in  [GitHub](https://github.com/koseven/koseven/issues), **there are absolutely no exceptions**.
 
 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.
 
 ## Creating new features
 
-New features or API breaking modifications should be developed in separate branches so as to isolate them
+New features or API breaking modifications should be developed in separate PR so as to isolate them
 until they're stable.
 
 **Features without tests written will be rejected! There are NO exceptions.**
@@ -84,20 +43,7 @@ Here's a quick example:
 **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 in the test to reference the bug's issue number
-(e.g. `@ticket 4045` for issue #4045). 
-
-If you run the unit tests then the one you've just made 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 both the fix and the test.
-
-**Bug fixes without tests written will be rejected! There are NO exceptions.**
-
-There is no need to create separate branches for bugfixes, creating them in the main develop
-branch is perfectly acceptable.
+Make a PR with the fix, explain as in detail as possiblle.
 
 ## Tagging releases
 
@@ -107,15 +53,15 @@ For example, if you were creating a tag for the `3.1.0` release the tag name wou
 
 # Merging changes from remote repositories
 
-Now that you have a remote repository, you can pull changes in the remote "kohana" repository
+Now that you have a remote repository, you can pull changes in the remote "koseven" repository
 into your local repository:
 
-    > git pull kohana 3.1/master
+    > git pull koseven 3.1/master
 
 **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 remote "kohana" repo.
+Sometimes a commit you've made locally will conflict with one made in the remote "koseven" repo.
 
 There are a couple of scenarios where this might happen:
 
@@ -130,7 +76,7 @@ The simplest way to fix this is to remove all the changes that you've made local
 
 You can do this using 
 
-    > git reset --hard kohana
+    > git reset --hard koseen
 
 ## You've fixed something locally which someone else has already fixed but you also have separate commits you'd like to keep
 
@@ -154,14 +100,14 @@ Git will remove the commit and you can then pull/merge the remote changes.
 
 # Unit Testing
 
-Kohana currently uses PHPUnit for unit testing. This is installed with composer.
+Koseven currently uses PHPUnit for unit testing. This is installed with composer.
 
 ## How to run the tests
 
  * Install [Phing](http://phing.info)
- * Make sure you have the [unittest](http://github.com/kohana/unittest) module enabled.
+ * Make sure you have the unittes module enabled.
  * Install [Composer](http://getcomposer.org)
  * Run `php composer.phar install` from the root of this repository
  * Finally, run `phing test`
 
-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.  
+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  and paste the output (including the error) in the issue.  

LICENSE.md

@@ -1,3 +1,17 @@
+# Koseven License Agreement
+
+This license is a legal agreement between you and the Koseven Team for the use of Koseven Framework (the "Software"). By obtaining the Software you agree to comply with the terms and conditions of this license.
+
+Copyright (c) 2016 Koseven Team  
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+* Neither the name of the Koseven nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+
+
 # Kohana License Agreement
 
 This license is a legal agreement between you and the Kohana Team for the use of Kohana Framework (the "Software"). By obtaining the Software you agree to comply with the terms and conditions of this license.

README.md

@@ -1,19 +1,52 @@
-# Kohana PHP Framework
+# Koseven PHP Framework
 
-[Kohana](http://kohanaframework.org/) is an elegant, open source, and object oriented HMVC framework built using PHP5, by a team of volunteers. It aims to be swift, secure, and small.
+Koseven is a PHP framework based on [Kohana](http://kohanaframework.org/) 3.3.X . Fully compatible with Kohana and updated to work with PHP7
 
-Released under a [BSD license](http://kohanaframework.org/license), Kohana can be used legally for any open source, commercial, or personal project.
+Koseven is an elegant, open source, and object oriented HMVC framework built using PHP7, by a team of volunteers. It aims to be swift, secure, and small.
+
+Released under a [BSD license](LICENSE.md), Koseven can be used legally for any open source, commercial, or personal project.
+
+## Why a Kohana alternative?
+
+I use Kohana 3.3.x in many live projects and migration will be really complex into any new PHP framework. Keeping the project alive and updated is a priority. Kohana team (which I belong too) aims to release 4.0.0 with many BC changes.
+
+I will keep updated tihs repo with any other new issues or features on Kohana.
+
+## Will work as dropin of Kohana
+
+If you were using 3.3.x version normally yes. Normally? theres 2 breaking changes that may affect you be aware. We have removed MySQL (you need to use MySQLi) and exception.php is now compatible with PHP7.
+
+We have also added the pagination module.
+
+## Are modules of Kohana compatible?
+
+Yes they are, jsut be sure are compatible with KO 3.3.X. 
+
+## Why all modules in 1 repo?
+
+This is a personal choice for me to keep the project as simple and easier to manage, modules are not enabled by default, just do not enable those you will not use.
+
+## Need help!
+
+We do not have a forum just yet (working on it), you cna in the meantime open a issue on github.
 
 ## Documentation
+
+We are working to improve currents Kohana's documentation but in the meantime fill free to use the one provided by KO.
+
 Kohana's documentation can be found at <http://kohanaframework.org/documentation> which also contains an API browser.
 
 The `userguide` module included in all Kohana releases also allows you to view the documentation locally. Once the `userguide` module is enabled in the bootstrap, it is accessible from your site via `/index.php/guide` (or just `/guide` if you are rewriting your URLs).
 
 ## Reporting bugs
-If you've stumbled across a bug, please help us out by [reporting the bug](http://dev.kohanaframework.org/projects/kohana3/) you have found. Simply log in or register and submit a new issue, leaving as much information about the bug as possible, e.g.
+If you've stumbled across a bug, please help us out by [reporting the bug](https://github.com/koseven/koseven/issues/new) you have found. Simply log in or register and submit a new issue, leaving as much information about the bug as possible, e.g.
 
 * Steps to reproduce
 * Expected result
 * Actual result
 
-This will help us to fix the bug as quickly as possible, and if you'd like to fix it yourself feel free to [fork us on GitHub](https://github.com/kohana) and submit a pull request!
+This will help us to fix the bug as quickly as possible, and if you'd like to fix it yourself feel free to [fork us on GitHub](https://github.com/koseven) and submit a pull request!
+
+## Contributing
+
+Any help is more than welcome! please see [Contributing](CONTRIBUTING.md)