Changelog

3.14 ( 2024 ETA )

Enhancements

Bug Fixes

Maintenance

3.13.2 ( 2024 July 19th )

Enhancements

Bug Fixes

3.13.1 ( 2024 June 16th )

Enhancements

Maintenance

Bug Fixes

3.12.1 ( 2023 August 3rd )

Enhancements

Maintenance

Bug Fixes

3.11.2 ( 2023 May 8th )

Enhancements

Bug Fixes

3.11.0 ( 2023 March 14th )

Enhancements

Bug Fixes

3.10.1 ( 2022 September 10th )

Enhancements

Bug Fixes

3.9.1 ( 2022 April 13th )

Enhancements

Bug Fixes

3.8.1 ( 2021 November 15th )

Enhancements

Bug Fixes

3.7.2 ( 2021 August 3rd )

Enhancements

Bug Fixes

3.7.1 ( 2021 July 20th )

Enhancements

Bug Fixes

3.6.2 ( 2021 March 17th )

Bug Fixes

3.6.1 ( 2021 March 16th )

Important Note

Lots of provisioners now run in strict mode. Your custom site and utility provisioners may fail if they do not handle bad return codes from commands correctly. For example if you ran composer create-project on a folder that was not empty, it will fail. In v3.5 this failure was ignored and the script continued despite the critical error, in v3.6 VVV will halt provisioning so that the error can be seen.

Make sure that commands are only ran at their appropriate times, e.g. only install things if they aren’t installed, and if you’re checking the return value of a command, do it in an if check, not as a temporary variable. If you’re feeling adventurous you can unset the strict flags ( danger! ).

Finally, check that your custom modifications haven’t been added in the official site templates.

Enhancements

Bug Fixes

3.5.1 ( 2020 December 11th )

Enhancements

Deprecations

Bug Fixes

3.4.1 ( 2020 June 4th )

Enhancements

Bug Fixes

3.3.0 ( 2020 Feb 26th )

Enhancements

Bug Fixes

3.2.0 ( 2019 Nov 5th )

Enhancements

Bug Fixes

3.1.1 ( 2019 August 6th )

This is a quick update that changes a default parameter when undefined. In VVV 2 the database was stored inside the VM, and in VVV 3 we put it in a shared folder. This didn’t work for some people, so we added a config option to disable this. If this option wasn’t set, VVV would use the shared folder.

In v3.1.1 if the option isn’t set, it will instead store the database inside the VM. This makes it work out of the box for everybody. If you have a working VVV with the shared folder, you can restore this behaviour by setting db_share_type: true in vvv-custom.yml and reprovisioning, see vvv-config.yml for an example of where this setting goes

Enhancements

Bug Fixes

3.1.0 ( 2019 July 4th )

This is primarily a reliability update. Note that updating to v3.1 requires a vagrant destroy and a vagrant up --provision. If you’ve turned off shared database folders, backup beforehand.

Enhancements

Bug Fixes

3.0.0 ( 17 May 2019 )

This version moves to an Ubuntu 18.04 box. It also moves the database data directory to a mounted folder. This means you can destroy and rebuild the VM without loss, but it also means a vagrant destroy is necessary to update. Be sure to back up database tables you need beforehand.

If you have issues provisioning with the new shared database folder, you can disable it by adding db_share_type: false to the general: section of vvv-custom.yml then reprovisioning. This will return you to the VVV 2 behaviour.

In the near future, we expect to use a box with PHP/etc preinstalled, this will be VVV 4.0.

Enhancements

Bug Fixes

Removals

2.6.0 ( 2nd April 2019 )

Enhancements

Bug Fixes

2.5.1 ( 14th January 2019 )

2.5 Brings a major bug fix, and some performance improvements to provisioning

Enhancements

Deprecations

Bug Fixes

2.4.0 ( 2018 October 2th )

Enhancements

Bug Fixes

2.3.0 ( 2018 September )

Enhancements

Bug Fixes

Deprecations

2.2.1 (May, 2018)

Note that to update to 2.2.1, you must remove the Vagrant triggers plugin and install Vagrant 2.1

Enhancements

Bug Fixes

Deprecations

2.1.0 (November 8, 2017)

Enhancements

Bugs

Documentation

Many updates to VVV’s documentation were made between the release of 2.0.0 and now. As of 2.1.0, the process to contributing to documentation has changed to use the varyingvagrantvagrants.org repository. This allows the workflow for shipping documentation changes to proceed separately from shipping VVV releases.

2.0.0 (March 13, 2017)

VVV 2.0.0 introduces breaking changes in how files are organized and introduces an entirely new method of configuration.

A full vagrant destroy and vagrant up are recommended for best results. Running vagrant destroy will remove your virtual machine entirely and all data stored on the VM will be lost. Please be sure to backup your databases and any files stored in the VM. Files on your local file system will remain, but will still benefit (as always) from a backup.

It is possible to make the from VVV 1.4.x to 2.0.0 without a vagrant destroy, but the process will involve restructuring several things. Primarily, default project directories are now expected to contain a public_html/ directory. This requires not only file changes, but new Nginx configurations. If you need help troubleshooting, don’t hesitate to open a new issue.

Please see the migration documentation for tips on how to manage this process.

The decision to include breaking changes in a release is not made lightly. The new ability to configure your installation of VVV with a vvv-custom.yml file will make VVV entirely more flexible and maintainable than it has ever been. Please see the release blog post and documentation for more details.

Features & Enhancements

Bugs

1.4.1 (January 16, 2017)

1.4.0 (November 2, 2016)

Bug fixes and Enhancements

1.3.0 (February 21, 2016)

Features

Bug fixes and enhancements

1.2.0 (December 14, 2014)

1.1

1.0

0.9

0.8

0.7

BREAKING CHANGES: Breaking changes are made in this release due to the reorganization of config files for PHP that will require a full vagrant destroy and vagrant up to resolve.

0.6

0.5

0.4

0.3

0.2.1

0.2

0.1