It's never too early to start talking about the long-term plan. Version 6.0 is probably at least a year or more out, depending on many, many factors. However, I want to share a vision of what I have in mind.
For the most part, this ticket is just to keep track of my thoughts today so that I can revisit them as we move toward 6.0 at some point in the future.
The move to Composer
Moving to Composer in 5.0 opened a lot of doors for us. No longer does everything have to be contained within the framework and shipped with every theme. Features can be separated into their own repos/packages.
This is very good because it means that every experimental feature that sounds like a good idea at the time can live in its own place. I don't have to regret adding it to the framework a year down the line. This has often been the case as things evolve in WP or just in general Web dev. It ends up creating back-compat issues when I remove a feature from the core framework.
The vision:
The ultimate goal is for Hybrid Core to just be the minimum code needed to tie all other features together. For example, the \Hybrid\Core\Application class is necessary to run the framework.
This way, we can pick and choose just the features that we want to use for any given project.
HC5 does a good job at separating some things. It's the starting point.
Potential packages:
Here's a quick list of some packages that could've very well been separated in 5.0 if I had chose to do so:
It's never too early to start talking about the long-term plan. Version 6.0 is probably at least a year or more out, depending on many, many factors. However, I want to share a vision of what I have in mind.
For the most part, this ticket is just to keep track of my thoughts today so that I can revisit them as we move toward 6.0 at some point in the future.
The move to Composer
Moving to Composer in 5.0 opened a lot of doors for us. No longer does everything have to be contained within the framework and shipped with every theme. Features can be separated into their own repos/packages.
This is very good because it means that every experimental feature that sounds like a good idea at the time can live in its own place. I don't have to regret adding it to the framework a year down the line. This has often been the case as things evolve in WP or just in general Web dev. It ends up creating back-compat issues when I remove a feature from the core framework.
The vision:
The ultimate goal is for Hybrid Core to just be the minimum code needed to tie all other features together. For example, the
\Hybrid\Core\Application
class is necessary to run the framework.This way, we can pick and choose just the features that we want to use for any given project.
HC5 does a good job at separating some things. It's the starting point.
Potential packages:
Here's a quick list of some packages that could've very well been separated in 5.0 if I had chose to do so: