search

wplib / wplib-box

The Best Local Dev Server for WordPress Developers
https://wplib.github.io/box-docs/
MIT License
209 stars 24 forks source link

Establish a Base Box Specification and Versioning/Release Strategy #155

Open mikeschinkel opened 8 years ago

mikeschinkel commented 8 years ago

With the prospect of Installable Packages on the horizon it is starting to become clear that we should establish a versioning/release strategy for the Box itself that goes beyond simple SemVer and more closely mirrors that of a Linux release.

Here is a strawman proposal:

Potentially we apply a name to a major release from a list of names in a category, for example maybe types of birds? So maybe the next major release could be "Hummingbird?"

Hummingbird would get a SemVer version number (e.g. 0.11.0) similar to how Apple OS/X has "El Capitan" which is version 10.11. Maybe we even call this version 1.0; the first major release that can support multiple domains without hacking the box?

Hummingbird could get a "Base Box Specification" which would contain the things that people can be guaranteed Hummingbird would always have, and that would not exceed with newer versions e.g.:

Component Software
OS Ubuntu 14.04 LTS
Nginx 1.4.x
PHP/PHP-FPM 7.0.x
MariaDB 10.1.x
XDEBUG 2.4.x
Redis 2.8.x
WP CLI 0.23.x
Nodejs 4.4.x

Note the list above is smaller than the current box, and is certainly not inclusive my any means as it would also contain the PHP extensions and other various things to be added.

We could then set up Installable Package testing that would be based on the Base Box Specification and Installable Packages would be specific to a major release.

Further let's say PHP 7.1 is released then we could create an Installable Package for it, maybe in with the name php7.1-hummingbird.boxpkg. Not yet sure if we'd need more than that to identify the package; would these need version numbers too? Or maybe version numbers are omitted for components developed for the platform vs. ones developed for WPLib Box by us or 3rd parties.

Also, anything that people would want their box to have could be configured using Installable Packages. If for some reason they want a box without PHP 7.0 but with PHP 5.6.x they could add in their "Provision Configuration" [1] that PHP7.0 is a package to remove then PHP5.6 is a package to add.

[1] First time I have mentioned this anywhere. I am thinking maybe we would have a .wplib-box directory in the root of the box install directory on peer with Vagrantfile and also a .wplib-box directory in each project directory. And inside those directories we could have a provision.json file containing a list of tasks or which two types could be remove-package and add-package.

On first vagrant up or vagrant reload --provision our provision script would look in .wplib-box/provision.json to see what tasks to run and then run them. And then when a project is added or removed the add/remove scripts could look in the project-specific .wplib-box/provision.json and see what tasks need to be run specifically for the given project. And obvious we'd need some conflict management built in for these but Debian Packages provide a great roadmap for requirements.

Thoughts? Discussion?

mikeschinkel commented 6 years ago

@MickMakes Something for us to review and decide if we've resolved it or still need to address.