Breaking Changes Coming

Unknown
Unknown
edited April 2015 in Dev & Ops

I wanted to talk about some breaking changes that are coming in Vanilla. @Linc will have to coordinate this kind of thing with the OSS side while there will be some infrastructure and dev support required too.

Composer Support

Vanilla will become a composer project. We are going to start by using it to autoload our core classes (everything in the /library dir). We will then be porting some of our vendor libraries and decoupling some of our monolithic development into composer components.

This means that Vanilla won't run until the requisite composer commands are called. To initialize the project you call composer install. To update composer dependencies and/or rebuild your autoloader call composer update.

Autoloader Rewrite and Dispatcher Refactor

We will rewrite the autoloader to increase speed and support a static map generation before deploys. Part of this rewrite will be removing support for classes with the same name within different contexts. The only place this occurs in Vanilla now is with the SettingsController. Currently each app has one and Vanilla knows which one to load. This is a complexity that needs to go. Here are the changes I am thinking.

  1. Deprecate and then remove the ability to call a route with /appname/controller. (ex. `/vanilla/settings).
  2. Add a way to route settings controllers differently. I am thinking that /settings/forum/* could route to the ForumSettingsController.
  3. Refactor the autoloader. When two classes with the same name exist then the autoloader will just pick one.
  4. Create a build tool for the open source zip that will include all composer dependancies.

Add support for an addon.json. Deprecate then remove Info Arrays

Currently we provide meta info about our various addons via a php array at the top of files. We currently have $PluginInfo, $ApplicationInfo, $ThemeInfo, and $LocaleInfo arrays. Parsing these various files is both unsafe and messy. I want to change the way this meta info is provided and eventually replace hundreds of lines of code with a single json_decode().

  1. Add support for an addon.json file that is put in the root of an addon directory. The file will be similar to a composer.json file, but will not have all of the features of composer.
  2. Provide a CLI tool to convert info arrays to addon.json files.

About Deprecating then Removing

When I talk about deprecating then removing the procedure will be as follows.

  1. Provide a grace period where both the deprecated and the new way work together.
  2. The deprecated way will produce deprecated notices to developers.
  3. Wait one or two releases.
  4. Remove the deprecated way.

That's about it. Please comment with any questions or concerns.

Comments

  • Unknown
    Unknown

    Added an addendum in the composer section:

    Create a build tool for the open source zip that will include all composer dependancies.

    This would be done with a composer script or phing or whatever. Just not an ad-hoc script.

Categories