BigTree 5: API and Backwards Compatibility
Back to BlogBigTree 5 is coming later this year with an all new API and many new features with the goal towards maintaining backward-compatibility with older site code.
BigTree 5 is coming later this year with an all new API and many new features with the goal towards maintaining backward-compatibility with older site code.
To anyone following BigTree for any amount of time, you'll know that we've been talking about the features coming to BigTree 4.3 for a long time now (almost two years!). As more and more features got added into 4.3 and the timetable slipped further and further it became clear that we should work toward a more forward-looking update to BigTree. Rather than calling this next version 4.3 we decided to label it 5.0 and build in features that are reserved for backwards-compatibility breaking releases.
One of the primary goals in all BigTree releases is to make upgrading as easy as possible. As developers who also work in other CMS platforms day to day (Drupal and WordPress specifically) we know that there are great benefits AND large drawbacks to maintaining 100% backwards compatibility. WordPress feels like you're building in the stone-age due to never moving on from a 13 year-old API while Drupal 8 feels like you're learning an entirely new platform and gain very little from your previous experience. We'd like to find a good middle ground where developers who are comfortable with the older API are free to continue using it but to use newer features and extensions you'll eventually have to move to the new API.
With BigTree 5.0 we're going to be shipping a "compat" set of classes that essentially are all the ones you know presently and love(?): BigTreeAdmin, BigTreeCMS, BigTree, BigTreeAutoModule, BigTreeStorage, etc. These compat classes should mimic the exact functionality of the classes from the 4.2 branch but are actually rewritten to piggyback on the new, more object-oriented, API classes in 5.0. We'll be writing a full blog post outlining the new classes as we approach the release but to give you an idea: BigTree\Page represents a page. You can create a new page with Page::create, save it using $page->save(), etc.
This will probably be the most controversial change as it affects the widest range of developers (the core team included – believe it or not our primary live servers were still running PHP 5.3 / MySQL 5.0 before we made this decision). BigTree 5.0 and higher will require PHP 7.1 and MySQL 5.5 to run. We didn't make this decision lightly but in the end decided that the benefits of the latest PHP and MySQL outweighed supported web hosts that are slow moving.
PHP 7.1 and MySQL 5.5 bring us:
In the end the choice came down to: do we want BigTree to be a forward looking CMS or to cling to backwards compatibility and fall behind like WordPress has? We chose to look forward with more modern coding practices and in the end that meant leaving support for PHP 5 and MySQL <5.5.3 behind.
Due to the BigTree 5 dropping support for outdated hosting environments we've decided to support the BigTree 4.2 branch indefinitely for our community that can't or doesn't have the time to update to BigTree 5. That means that for the foreseeable future there will not be a cut-off date for when BigTree 4.2 stops receiving bug and security fixes. That said, feature updates will be exclusive to the BigTree 5.0 branch once it is released. Up to that time, you may see BigTree 4.2 getting small feature updates along the road.