Joomla has great plans for the future of the CMS. Below are a few of the ideas which have been raised for upcoming releases. When writing a revised roadmap we started by determining what we hoped to accomplish.
Light Core and Core Supported Extensions
Based on feedback the concept of a light core for the Joomla CMS was established. The next step was determining how to achieve a light core and what parts were necessary in this light core version. Obviously there are many opinions on how a light core should be realized, what should be included, and what should be removed. We determined a list of core components which should remain within the CMS and a list of components which could legitimately be removed from core and added to a ‘core supported’ extension category.
Justification for this particular set of extensions is a result of much discussion and debate. One determining factor was the availability of better alternatives located through other third-party sources. Not all of the above extensions may have well-known alternatives but most do.
Note: It should be noted what is meant by a core-supported extension. The Joomla CMS is determined to offer an incredible level of backwards compatibility and stability to the community. This does not mean that the CMS should not be able to make progress. It merely means the progress should be handled thoughtfully and carefully. In order to make a light core CMS we must begin removing extensions. We must do so carefully and preserve backwards compatibility. Here is the plan to accomplish this goal.
New JED Category
First, a new category will be created within the Joomla extension directory. This category will be reserved for only those extensions marked as core-supported. Initially the core-supported extensions will be only those listed above and any defined as core-supported by the Production Leadership Team. It will be important at the time of launch to have more than just the existing extensions listed. This will demonstrate the active development of these extensions and that these extensions are not merely legacy archives.
The next step is to make these core-supported extensions incredibly easy to add to the CMS. This means it should be installable immediately upon installation of the CMS. This will be accomplished by first making the recent install from web plugin part of the core CMS and enabled by default. Although there was some debate surrounding this plugin initially it has at this point been battle-tested and proven to be sufficient. The code will continue to be improved over time. By making this plugin part of the core CMS and enabled by default it will allow the CMS to be redirected to this screen through the post-install message. The install from web screen will open directly to the core-supported extension category where the user will be able to immediately install any of the original or new core-supported extensions.
Special GitHub Repository
A new GitHub organization (already created) will be used to hold each of the core supported extensions and allow for individual upgrades, improvements, and releases. There are many benefits to this option and hopefully will lead to improved support and maintenance of each of the extensions.
One question raised was in regards to maintaining backwards compatibility. Any existing CMS installations when upgrading will not lose existing extensions. With each release the goal will be to make the individual extensions un-installable and removable. If the user then wishes to re-install any extension they can do so through the install from web or core-supported Joomla extensions.
To begin this careful process of removing extensions a single extension will be removed as a test case in a single release to work out any possible issues. This release will remove the weblinks component from core, setup the core distributed category of the Joomla Extension Directory, establish a post-install message/link to this new category within the install from web option, and make the weblinks extensions uninstallable on existing CMS upgrades.
Doing this will maintain backwards compatibility and allow the CMS to take a major step towards a light core. Upon a successful release this same process will be repeated with the other identified extensions.
This covers one of the features of the proposed new release cycle. Next we looked at how to structure the timeframes of releases and how to relate these releases to the new proposed development cycle listed above and previously discussed.
Timeframes of releases and semantic versions
With the proposed new development cycle above one of the key features is maintaining long-term stability and backwards compatibility while also beginning to follow a semantic versioning approach to releases. The other aspect of timeframes was previously identified as a problem with the current release cycle. This ties in closely to the version numbers and release dates. By changing the releases to a somewhat standardized semantic version numbering and increasing the number of releases we will be able to stop the rush to include bugs and improvements in a release. Ideally the goal is to minimize the amount of items to be included in each release but also offer a more frequent release cycle. Important to keep in mind: these releases are considered minor releases and none of them are to break backwards compatibility. Any features determined to break backwards compatibility will be moved to the next major release.
Steps of the suggested roadmap
Please remember all dates are tentative and proposed focus for each release subject to modification:
||1st quarter 2017|
||3rd quarter 2017|
||3rd quarter 2017|
Apart from those items mentioned above, we will also be interested to see any contributions in the following areas:
- Features to improve SEO.
- Hypermedia API (webservices).
- Improvements to installation process:
- Ability to install extensions (at minimum core supported extensions)
- Rework sample data installation
- Continued work on the GSOC Multilingual editing proposal.
- A new administrator template with minimal options.
When ready these could be shipped with the next available release. Any other features not on this roadmap will be considered on their merit should they reach a merge-able state. The Roadmap is subject to change in the light of ongoing experience and will be formally reviewed at the next PLT Summit meeting currently scheduled for JAB 2017.