Masonite Documentation
v1.5
v1.5
  • Introduction
  • Prologue
    • Introduction and Installaton
    • Contributing Guide
    • How To Contribute
    • Release Cycle
  • What's New
    • Masonite 1.3
    • Masonite 1.4
    • Masonite 1.5
  • Upgrade Guide
    • Masonite 1.3 to 1.4
    • Masonite 1.4 to 1.5
  • The Basics
    • Routing
    • Controllers
    • Views
    • Requests
    • Static Files
    • Helper Functions
  • The Craft Command
    • Introduction
    • Creating Commands
    • Authentication System
  • Architectural Concepts
    • Request Lifecycle
    • Service Providers
    • Service Container
  • Advanced
    • Middleware
    • Validation
    • Creating Packages
    • Extending Classes
    • Creating a Mail Driver
    • Sessions
  • Useful Features
    • Template Caching
    • Mail
    • Uploading
    • View Composers and Sharing
    • Caching
    • Broadcasting
    • Queues and Jobs
    • Compiling Assets
  • Security
    • Authentication
    • Encryption
    • CSRF Protection
  • Orator ORM
    • Basic Usage
    • Query Builder
    • ORM
    • Pagination
    • Schema Builder
    • Database Migrations
    • Collections
  • Managers and Drivers
    • About Managers
    • About Drivers
    • Contracts
  • Official Packages
    • Masonite Entry
    • Masonite Billing
  • Creating Your First Blog
    • Introduction
    • Part 1 - Creating Our First Route
    • Part 2 - Creating Our First Controller
    • Part 3 - Designing Our Blog
    • Part 4 - Migrations
    • Part 5 - Models
    • Part 3 - Authentication
Powered by GitBook
On this page
  • Introduction
  • Reasoning for RomVer over SemVer
  • Releases and Release Cycles
  • Scheduled Releases
  • Creating Releases
  • Main Repository and New Projects
Edit on Git
Export as PDF
  1. Prologue

Release Cycle

Introduction

The Masonite framework itself follows the RomVer versioning schema which is PARADIGM.MAJOR.MINOR although all Masonite packages follow the SemVer versioning schema which is MAJOR.MINOR.FEATURE/BUGFIX.

This means that a framework version of 1.3.20 will have breaking changes with version 1.4.0.

Reasoning for RomVer over SemVer

The Masonite main repository (the MiraFramework/masonite repository) contains only the basic file structure of the application. All of the core framework functionality is inside the MasoniteFramework/core repository which can be updated as much as every day or once per month and therefore will follow normal SemVer. Because MiraFramework/masonite does not require major updates, we can follow RomVer nicely and keep the versioning number artificially lower. Any major updates to this repsository will likely just be file structure changes which should rarely happen unless there are major architectural changes.

Releases and Release Cycles

Masonite is currently on a 1 month major release cycle. This means that once every month will be a new 1.x release. This 1 month release cycle will continue until Masonite has reached a release that is stable enough to move far into the future with that releases architecture.

Once this stable release has been achieved, Masonite will move to a 6 month major release cycle with minor releases as often as every few days to as much as every few months.

Releases are planned to be upgradable from the previous release in 10 minutes or less. If they break that requirement then they should be considered for the next Paradigm release (the x.0.0 release)

Scheduled Releases

Creating Releases

Masonite is made up of three different repositories. There is

  • The main repository where development is done on the repo that installs on developer's systems.

  • The core repository which is where the main Masonite pip package is located.

  • The craft repository where the craft command tool is located.

Major 1 month releases will be released on or after the release date when all repositories are able to be released at the same time, as well as passing all tests.

Whenever the MasoniteFramework/craft and MasoniteFramework/core repositories are released on Github, Travis CI will run tests and automatically deploy to PyPi. These major version numbers should correspond to the version of Masonite they support. For example, if the MasoniteFramework/masonite releases to version 1.4, MasoniteFramework/core should bump up to 1.4.x regardless of changes.

Main Repository and New Projects

This is so developers and maintainers will be able to test the new pre release with their applications. Once all QA tests have passed, it will be marked as a normal release and therefore all new applications created from there on out will be the new release.

Developers will still have the option of doing something like: craft new project_name --version 1.5 and installing that version of Masonite.

Once all three repositories are ready for release, they will all be released on GitHub under the respective new version numbers.

PreviousHow To ContributeNextMasonite 1.3

Last updated 7 years ago

The main repository which is MasoniteFramework/masonite does not have a corresponding PyPi package and is only for installing new Masonite projects. See the craft new command under documentation. The craft new command will download a zip of the latest release of Masonite, unzip it and rename the folder. Once the next release for this repository is ready, it will be released but marked as a Pre-release and therefore will not be installable by the default craft new command.

The Craft Command