MasoniteFramework/cookie-cutterrepository is the main repository that will install when creating new projects using the
craft newcommand. This is actually a full Masonite project. When you run
craft newit simply reaches out to this GitHub repo, fetches the zip and unzips it on your computer. Not much development will be done in this repository and won't be changed unless something requires changes in the default installation.
MasoniteFramework/corerepository is deprecated and development has been moved into
Masoniteframework/masonite. This repository contains all the development of Masonite and contains all the releases for Masonite. If you need to fix a bug or add a new feature then this is the repository to fork.
MasoniteFramework/craftis deprecated. This was where the craft CLI tool lives that has since been moved into the
masoniterepository. Masonite 2.2 and below still requires repository so if you need to make a change to craft for Masonite 2.2 then you can do so in this repo. If you need to make a change to craft in Masonite 2.3 and above then do so directly in
git clone http://github.com/your-username/cookie-cutter.git
git checkout -b develop
git pull origin developto get the current release version.
<feature|fix>-<issue-number>) and make your desired changes.
git push origin change-default-orm
git clone http://github.com/your-username/masonite.git
cdinto the directory you installed core.
pip install .from inside the masonite-core directory. This will install masonite as a pip package.
If the change in Masonite's CLI tool is for 2.3 or above, please make the changes in the
git clone http://github.com/your-username/craft.git
pip install --editable .from inside the masonite-cli directory. This will install craft (which contains the craft commands) as a pip package but also keep a reference to the folder so you can make changes freely to craft commands while not having to worry about continuously reinstalling it.
#comment above it
MasoniteFramework/docsrepo (and the README.md inside
MasoniteFramework/masoniterepo if applicable) with details of changes to the UI. This includes new environment variables, new file locations, container parameters, new feature explanations etc.
<feature|fix>/<issue-number>. For example if you are doing a bug fix and the issue number is
576then name your branch
fix/576. This will help us locate the branches on our computers at later dates. If it is a new feature name it
masoniterepo require unit testing.
2.3. 4) Previous release branches are the same thing but instead are just previous versions. So if Masonite is currently on
2.3then the previous release branches could be
2.2, etc. 5) The master branch is a staging branch that will eventually be merged into the current release branch. Here is where all non breaking changes will be staged (new non breaking features and bug fixes). 6) The develop branch is a staging branch to the next major version. So for example, Masonite will be on version
2.3. If you have an idea for a feature but it will break the existing feature then you will branch from (and back into) the
developbranch. This branch will eventually be merged into
2.4and become apart of the next major version when that is released.
developbranch. You will make your change and then open a pull request to the
developbranch. This is a long running branch and will merge once the next major version of Masonite is ready to be released.