2018-01-05, 06:46 PM
This was originally posted in response to another thread, but in the interests of clarity, I'm posting it as a new thread stuck within this forum.
This roadmap will be updated as development progresses.
Plan for a 1.9.0 release as the next major release. This release would:
Once 1.10.0 is released, work towards the next major vesion as 1.11.0. This release would:
In the background, as this process happens, we could continuously work on larger refinements and enhancements such as adding a CLI tool to the core, rewriting the ACP to make use of templates, etc. These major additions and changes could be rolled into the next major release (where the middle version changes, such as 1.8 -> 1.9 or 1.9 -> 1.10).
Also of note for this approach is a slight change to how we number versions. Currently, we skip odd numbers and call them development versions. This is pretty odd, and makes little sense when the numbers don't actually get used anywhere in the core. With this roadmap we'd be using verison numbers in a way that makes more sense.
This roadmap will be updated as development progresses.
Plan for a 1.9.0 release as the next major release. This release would:
- Bump required PHP vesion to PHP 7.1 in anticipation for the future. [DONE]
- Implement Twig as a template engine. [IN-PROGRESS]
- Introduce Composer to manage 3rd party dependencies and provide autoloading [DONE]
- Introduce the SwiftMailer library to handle the sending of emails, fixing compatibiltiy issues with different SMTP hosts. [DONE]
- Introduce a brand new theme which would be fully responsive and mobile ready. [IN-PROGRESS]
- Introduce user alerts to the core, alerting users of new PMs, replies to threads, etc.
- Look at introducing other 3rd party components (such as introducing a third party caching library to add more cache drivers, introducing a new query builder to be used whenever new features are added or reworked).
Once 1.10.0 is released, work towards the next major vesion as 1.11.0. This release would:
- Bring in conversations as a replacement for Private Messages, and integrate them with the alerts system from 1.10.0.
- Continue introducing other 3rd party components.
- Look at changing the plugin structure to make use of Composer and provide plugins as Composer packages. This would:
- Allow plugins to easily register classes in the autoloader
- Make it easier for plugins to add new JS, CSS, etc. as plugins would all extend a base class that would provide common funcitonality - much like the 3rd party PluginLibrary project by frostschutz does
- Make it possible in the future to automate the installation of plugins straight from the Admin Control Panel, as all plugins would follow a common structure.
- Allow plugins to easily register classes in the autoloader
- Continue introducing other 3rd party components.
In the background, as this process happens, we could continuously work on larger refinements and enhancements such as adding a CLI tool to the core, rewriting the ACP to make use of templates, etc. These major additions and changes could be rolled into the next major release (where the middle version changes, such as 1.8 -> 1.9 or 1.9 -> 1.10).
Also of note for this approach is a slight change to how we number versions. Currently, we skip odd numbers and call them development versions. This is pretty odd, and makes little sense when the numbers don't actually get used anywhere in the core. With this roadmap we'd be using verison numbers in a way that makes more sense.