Varying Vagrant Vagrants logo Varying Vagrant Vagrants

Subscribe with RSS to keep up with the latest changes.

VVV 3.1.0

July 04, 2019

Hi! Welcome to the very late release post for VVV v3.1.0.

This is primarily a reliability update. Note that updating to v3.1 requires a vagrant destroy and a vagrant up --provision. Back up your database before updating.

Enhancements

  • The vagrant box can now be overriden using the box parameter in vvv-custom.yml under the vm_config section. This requires a vagrant destroy followed by a vagrant up --provision to recreate the VM using the new box
  • The main provisioner now only fetches the apt keys once rather than on every key check
  • The TTY fix shell provisioner and the /vagrant setup shell provisioner were merged for a minor reduction in provisioning time.
  • Allow db_backup script to be run manually regardless if automatic DB backups are disabled
  • vvv, vvv.dev, and vvv.local now redirect to vvv.test
  • Added a premade Sequel Pro config file under the database folder
  • Set GitHub token from vvv-custom.yml for Composer

Bug Fixes

  • Changed to the ubuntu/bionic64 box to avoid issues with kernel page cache corruption until they can be identified, these were causing issues when updating a WP installation
  • Fixes to mysql user and group creation to improve shared folder reliability
  • Fixed an issue with permissions in files copied to the home folder
  • Fixed shared folder and permissions for Microsoft Hyper-V
  • Fixed all mount_options to the correct permissions for Microsoft Hyper-V
  • Set VM Name to exactly the same as VirtualBox, using v.vmname for Hyper-V
  • Fixes to log file paths for XDebug and PHP
  • Fixes files and folders in the home folder being owned by root instead of vagrant
  • Fixes support for database names containing hyphens in the import/restore scripts
  • Fixes the site provisioner attempting to clone site templates into existing sites when a site template is added to a site that didn’t have one before, but has already provisioned ( it will note that this happened but won’t clone the template )
  • Removed some references to Go
  • Fixed symlink issues with apt source files by copying instead
  • Specify keep_colors on vagrant provisioners to prevent composer from outputting valid messages in the red error colours, unnecessarily alarming users
  • xdebug_on and xdebug_off now toggle Tideways so that XDebug and Tideways are never running at the same time
  • Switched to Node v10 by default to fix compatibility issues with the WP Core build scripts
  • Runs the npm commands in the main provisioner under the vagrant user
  • Node v11 is now auto-downgraded to Node v10
  • Fixed Database SSH access from the host by enabling password authentication in /etc/ssh/sshd_config
  • Added code to remove NVM
  • Change Permission folder /vagrant from root to vagrant

VVV 3.0

May 15, 2019

Hi! Welcome to the very late release post for VVV v3.0. As we follow semantic versioning, this is a breaking release, and requires slightly different update instructions.

Ubuntu 14 EOL and moving to Ubuntu 18 LTS

VVV 2 uses Ubuntu 14, but this reached end of life recently. In response Ondrej deleted the unsupported PHP packages, and all VVV 2 installs were no longer able to provision. VVV contributors had setup a package mirror in case this had happened, but it seems only 70% of the needed packages were mirrored.

For this reason, VVV 2 is no longer supported, and won’t be recieving fixes and updates.

VVV 3 moves us to a new Ubuntu 18.04 LTS box, which should cover us until 2024. Additionally, we’re using a leaner custom built box. This does mean that you will need to destroy your VM to update:

# turn off the VM
vagrant halt
# destroy the Ubuntu 14 VM
vagrant destroy
# pull down the latest update
git pull
# provision a shiny new Ubuntu 18 VM
vagrant up --provision

This will destroy the database, but luckily VVV has been creating backups for a long time, you can restore them after updating with this command:

vagrant ssh -c "db_restore"

If you turned off database backups, you can manually back up your database before updating with this command:

vagrant ssh -c "db_backup"

What Else Has Changed?

MariaDB data No Longer Inside the VM

VVV3 stores its database in database/data now, which means it will survive a vagrant destroy. If you’re having trouble provisioning mariadb, let us know on github issues.

We also added a config option to return to the old behaviour for those having problems:

general:
  db_share_type: false

We continued optimising provision in this release, and making VVV friendlier.

Vagrant Guest Additions Plugin Disabled

Our new box has recent guest additions, so this shouldn’t be needed. However, some users like this plugin, and when reprovisioning encountered problems. We’ve disabled the plugin just for VVV to avoid these issues.

Changes To Utilities

Utilities are now simpler and easier to work with and debug:

  • TLS certificates are now accessed via a new /srv/certificates folder
  • Utilities are now announced with messages for if no provisioner was found
  • The trusted hosts utility has been deprecated and merged into the core provisioner, fixing several dashboard cloning issues
  • VVV2 referred to utilities internally as resources, this has been changed to utilities, and they’re now cloned to the provision/utilities folder

Mapped Folder Changes

With this release, we removed the /vagrant mapped folder and eliminated overlapping vagrant shared folders. This improves compatibility, the new shares are:

  • /srv/provision -> provision
  • /srv/certificates -> certificates
  • /srv/config -> config
  • /srv/database -> database/sql
  • /var/lib/mysql -> database/data
  • /var/logs/nginx -> logs/nginx
  • /var/logs/php -> logs/php
  • /var/logs/memcached -> logs/memcached
  • /srv/www -> www

VVV will now copy the version and vvv-custom.yml file on provision into /vagrant inside the VM, but this folder is no longer mounted and is erased on every provision prior to copying.

Ubuntu 18 Changes

Ubuntu brings with it lots of Kernel improvements that make Ubuntu faster in a virtual machine. Expect to see small to large performance improvements in some areas depending on your machine and workload.

We also had the opportunity to update some packages, Mongodb has been updated from v3.4 to v4.0, and various security improvements have been inherited.

Provisioning Improvements

We also improved the provisioners:

  • The Git PPA is now only added if it’s missing
  • Various composer and git commands now run as root ( VirtualBox determines the ownership of those folders, so they will always be owned by the vagrant user )
  • The branch and repo URL are mentioned when cloning dashboards, sites, and utilities
  • the VVV splash no longer shows on a halt or suspend
  • when provisioning on Ubuntu 14 it aborts and gives instructions on updating
  • added the VVV PPA package mirror
  • nginx now gets reloaded instead of restarted
  • VVV now copies over a minimal MySQL config for overrides
  • Added git-svn support
  • Provisioners now log their output to logs/provisioners/datetime/provisionername.log in addition to showing in the terminal
  • nvm was removed from the core provisioner, it made a network request on every provision, and downloaded a script that always failed with syntax errors

VirtualBox and Vagrant Versions

If you’re using the 6.x versions of VirtualBox, be sure to update to v6.0.8 which contains several important fixes regarding shared folders.

We also now require Vagrant v2.2.4 as a minimum version.

.dev Domains Removed

We deprecated these a while ago, but vvv.dev is no longer added as a host or listened for by Nginx. We also removed vvv.local, and vvv.localhost to avoid confusion. From now on vvv.test is the dashboard URL.

As an aside, vvv gets added, and we’d like to remove it, but aren’t sure how. If you know how to do it, let us know!

Finally, a Big Thank You To Our Testers

To make sure we eliminated as many kinks and issues as possible, we had a large pool of testers, community members who took their own time to help verify and find problems. I have no doubt some still remain, and I hope a v3.1 will be out in the next week or two. Dealing with the sudden changes to Ubuntu 14 have been tough on a lot of people, and a major disruption to others, thank you for being patient!

VVV 2.6

April 01, 2019

Hi! Welcome to the very late release post for VVV v2.6. For help updating, see the documentation on keeping VVV up to date.

We continued optimising provision in this release, and making VVV friendlier.

Splash and Completion Messages

We improved our splash screen to contain better debug info for when users raise GitHub issues. We also noticed that users who finished provisioning weren’t sure if it had finished or stopped. To fix this, we added a big message that appears at the end of provisioning and vagrant up to make it clear the process has finished:

new vagrant up end message

Hosts Updater AutoDownload

If the gem for hostsupdater is in the same folder, but the plugin isn’t installed, it will auto-install it. It will also try to auto-install via Vagrant. VVV requires hostsupdater to function as expected.

2.4 also allowed Utilities to add their own Nginx configs, and renamed the sites that come bundled with VVV by default. 2.4 also fixed some logging issues with PHP. Otherwise v2.4 was a short release that focused on cleaning up messaging.

Contributor Day Changes

A wordcamp_contributor_day_box option was added to the config file to make it easy for contributor day users to switch to mainline VVV.

Tideways and xhgui Profiling

If you add tideways to your utilities section as shown in the default vvv-config.yml then reprovision, you will gain access to xhgui and advanced PHP profiling features. Add ?enable-tideways to a URL and it will show up in xhgui at http://xhgui.vvv.test

A screenshot of a single request open in xhgui

VVV 2.4 and 2.5

March 31, 2019

Hi! Welcome to the very late release post for VVV v2.4 and v2.5. For help updating, see the documentation on keeping VVV up to date.

Here’s what’s happening…

Notable Changes in 2.4

Both versions focused on optimising the provisioning process further, 2.4 continues this by only provisioning hosts for active sites.

2.4 also allowed Utilities to add their own Nginx configs, and renamed the sites that come bundled with VVV by default. 2.4 also fixed some logging issues with PHP. Otherwise v2.4 was a short release that focused on cleaning up messaging.

Notable Changes in v2.5

2.5 made a number of provisioning improvements and general updates:

  • DB backups can now be turned on and off in the config file, see vvv-config.yml for details
  • MailHog is installed via binaries rather than being built from source, saving a lot of time, and removing golang
  • VVV now preferentially loads provisioner files from .vvv and provision, if they’re found it won’t search the subfolders for provisioner files
  • VVV warns you if you don’t put any hosts on your site
  • Site provisioners can now use {vvv_tls_cert} and {vvv_tls_key}, no need for a sed command to add them
  • More warnings and messages for provisioners to make it clearer what’s going on

A Reminder, Uninstall Vagrant Triggers and upgrade Vagrant to 2.2.4+

At the time of writing the latest Vagrant version is 2.2.4, we strongly recommend updating. The Vagrant triggers plugin is also no longer required, as it was merged into Vagrant 2.1.

Remember:

  • VirtualBox creates the VM
  • Vagrant manages the VM, turning it on and off, configuring it
  • VVV tels vagrant how to configure it, and how to install things

This does mean that users with the triggers plugin installed will get a warning when using vagrant commands. Read the warning for a parameter that can be added to silence the warning if you still need vagrant triggers for pre-2.1 vagrant environments. Otherwise, uninstall vagrant triggers with the following command:

vagrant plugin uninstall vagrant-triggers

We recommend a minimum of Vagrant 2.2.4, and suggest avoiding v2.1.3 which is known to be a broken Vagrant release.

Varying Vagrant Vagrants 2.3.0

September 30, 2018

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.3.0. For help updating, see the documentation on keeping VVV up to date.

Here’s what’s happening…

MailCatcher Replaced With MailHog

MailCatcher was proving difficult to support, and very fragile. In response, we’ve now replaced it with the superior MailHog. MailHog can be accessed via the dashboard at vvv.test

Git LFS

Support was added for Git LFS type repositories, and has been tested with site templates. No additional steps are needed on the VVV side to support this.

Improved Fallbacks

VVV will no longer continue to provision if packages installation or network detection fails. We’ve also changed our tests to use the Launchpad PPA servers rather than Google, enabling Chinese users to run VVV!

We also:

  • Improved the built in terminal prompt
  • Removed the MOTD instruction to manually update packages that broke VVV installs
  • Bundled the apt-get keys as some users failed to retrieve them for unknown reasons

VVV searches 3 levels down for vvv_hosts

Instead of searching 4 levels down, VVV will search 3 folders down. There has also been performance improvements by explicitly searching for provisioner files where VVV expects them, and avoiding the search altogether.

Remember, vvv_hosts support, and being able to put provisioner files anywhere is included for legacy support reasons only. Nested VVV sites can be handled via the vm_dir and local_dir parameters without requiring slow filesystem searches.

Logs

Logs are now owned by the vagant user not the ubuntu user, which should improve support for providers such as hyperV and others

A Reminder, Uninstall Vagrant Triggers and upgrade Vagrant to 2.1.5+

Since v2.2.x VVV now requires Vagrant 2.1 to run. The Vagrant triggers plugin is also no longer required, as it was merged into Vagrant 2.1.

Remember:

  • VirtualBox creates the VM
  • Vagrant manages the VM, turning it on and off, configuring it
  • VVV tels vagrant how to configure it, and how to install things

This does mean that users with the triggers plugin installed will get a warning when using vagrant commands. Read the warning for a parameter that can be added to silence the warning if you still need vagrant triggers for pre-2.1 vagrant environments. Otherwise, uninstall vagrant triggers with the following command:

vagrant plugin uninstall vagrant-triggers

We recommend a minimum of Vagrant 2.1.4, and suggest avoiding v2.1.3 which is known to be a broken Vagrant release.

Varying Vagrant Vagrants 2.2.1

May 22, 2018

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.2.1. For help updating, see the documentation on keeping VVV up to date.

Here’s what’s happening…

Vagrant Triggers and Vagrant 2.1

VVV now requires Vagrant 2.1 to run. The Vagrant triggers plugin is also no longer required, as it was merged into Vagrant 2.1.

This does mean that users with the triggers plugin installed will get a warning when using vagrant commands. Read the warning for a parameter that can be added to silence the warning if you still need vagrant triggers for pre-2.1 vagrant environments. Otherwise, uninstall vagrant triggers with the following command:

vagrant plugin uninstall vagrant-triggers

PHP 7.2

VVV now uses PHP 7.2 by default. See here on how to change a sites PHP version.

TLS

Testing with https is an important part of development, so we’ve added a new TLS-CA utility, that comes with new installs by default. This installs a certificate authority just for your machine, letting you test https:// addresses locally.

To use this, add the utility, and reprovision. Then, you need to tell your OS or browser to accept the root certificate for the authority. This tells your computer to trust any certificates it generates, without which you’ll get a warning when visiting sites. This can be found in your VVV folder under certificates/ca/ca.crt.

For more information, see our docs here

Custom Site Template Develop and Deprecations

The wordpress-develop repository has been deprecated! This old site template was hardcoded to a single URL, and had other issues. It’s replaced by custom-site-template-develop, which allows for multiple WP core development environments.

Additionally, the src. subdomain is going away due to changes in the WP core development process.

Logs

Logs are now in the /var/log folder, which is mounted on to the log folder in your install. In particular, the default Nginx log, and the MariaDB logs are now in /var/log

Dashboard

Is now a separate git repo! And updates independently of VVV on vagrant provision. You can also override the dashboard in vvv-custom.yml via the dashboard options:

dashboard:
  repo: ....
  branch; ...

Project Notes

We’ve added a new contributor team for testers and reviewers, Benjamin Lu and Daniele Scasciafratte. They’ve been very helpful in issues and testing changes. We’ve also added Tom J Nowell as a lead developer.

Varying Vagrant Vagrants 2.1.0

November 08, 2017

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.1.0. For help updating, see the documentation on keeping VVV up to date.

Here’s what’s happening…

A new TLD for default sites

The .test TLD is now used for all default VVV sites instead of .dev.

You may have noticed back in September that Google added their .dev TLD to the HTTPS preload list in Google Chrome. This means that in recent versions of Chrome .dev domains are forced to use HTTPS.

Up until this point, VVV relied heavily on the .dev TLD and moving to a TLD that isn’t owned by anyone is a pretty obvious move. After quite a bit of discussion, we determined that .test was the best of the options laid out in RFC2606.

Because we can’t detect all customizations made to default sites, automatically updating everything isn’t an option. Default sites like src.wordpress-develop.dev will still work at their current URLs and will require a bit of manual effort to move over to src.wordpress-develop.test.

With WP-CLI, it’s pretty straight forward:

  • vagrant ssh
  • cd /srv/www/wordpress-develop/public_html
  • wp search-replace '.dev' '.test' --recurse-objects --network

On new provisions of VVV, this will all be setup automatically. On your own custom sites, you’ll need to adjust accordingly. Embrace the .test domain!

Update: We’ve added more extensive instructions for migrating from .dev to .test here

Thanks to Gary for warning us about this 2.5 years ago. :)

Better and better documentation

Many updates to VVV’s documentation on varyingvagrantvagrants.org were made between the release of 2.0.0 and now.

The process to contributing to documentation has changed to use the varyingvagrantvagrants.org repository. This clears the workflow for shipping documentation changes to proceed separately from shipping VVV releases.

There has also been a great improvement in the quality and presentation of the documentation. Things look great, are navigable, and you can search!

As a bonus, check out all the excellent work that’s been done on the VVV dashboard at your local http://vvv.test site.

A screenshot of the new dashboard used in VVV 2.1.0

And more

A full changelog is up that has all of the details for this release. We fixed MailCatcher, made some tweaks to how PHPCS is installed and its configuration, and applied some small adjustments to the VM configuration.

Project notes

Wayyyyyy back in April, we added Tom J Nowell as a VVV committer and he’s been doing a fantastic job of staying on top of things. He’s been a prolific contributor this year, much of the current state of our documentation structure is due to his work, and he made our excellent logo!

Future thoughts

There’s always a lot to think about for the future of VVV, but I’ll note a couple things that are coming up:

  • At some point we’ll want to move to the latest Ubuntu LTS release. This will be a breaking change and require a 3.x.x.
  • We may also take this opportunity to refactor how provisioning is done and instead provide our own base box.
  • Have more ideas? Come on over and participate!

That’s all for 2.1.0. A big thank you to every one of our contributors and thank you for using VVV!

Varying Vagrant Vagrants 2.0.0

March 13, 2017

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.0.0.

A new method for configuring VVV

One of the things that’s been on the VVV wish list for a long time is support for a YAML configuration file. So much gets provisioned by default, it’d be nice to have a bit more control over that.

VVV 2.0.0 introduces a YAML configuration for VVV. A vvv-config.yml file is provided with defaults. This can be copied to a vvv-custom.yml file that lets you adjust VVV to fit your needs.

Part of this feature includes making the default provisioning a bit more module. Pieces have been broken out into a handful of repositories:

  • A new VVV utilities repository controls the utilities installed by default. It’s now possible to manage this list and even add to it with your own utilities repo.
  • A VVV WordPress Develop repository is used to make contributing to WordPress easier.
  • A VVV WordPress Default repository gives you the latest version of WordPress.

A really exciting part of the new configuration is how easy it is to add a site to your configuration. It’s now possible to choose PHP 5.6, 7.0, or 7.1 for your project and the new VVV Custom Site Template repository makes things even easier by providing a flexible base for new projects.

A big thanks to Lorelei Aurora for leading this feature. It’s hard to describe how excellent this improvement is.

The initial documentation for all of this is available, and we’ll continue improving on it over the next few weeks. Please note that this is considered a breaking change, hence the version bump to 2.0.0. More detailed guidance on these changes can be found in the changelog.

A new home for documentation

Part of the process for introducing the new YAML configuration was introducing documentation for it as well. Thanks primarily to Tom J Nowell, the documentation available for VVV has improved significantly in this release.

Docs are included as part of the repository and built into their final form at varyingvagrantvagrants.org/docs/en-US/.

Over the next few months, documentation will continue to improve as content is migrated from the wiki on GitHub to the new site. A big item on the roadmap is introducing a translation workflow so that documentation can be available in any language.

And much more

A full changelog is up that has all of the details for this release. Take note of the upgrade from MySQL 5.5 to MariaDB 10.1, the inclusion of the php-memcached package for better object cache support, and the change in how WP-CLI is installed and updated.

Project notes

An important housekeeping item for this release is the introduction of a governance document. This helps explain how the VVV project is managed and what the various roles and responsibilities are.

And finally, as mentioned earlier in the post, Lorelei Aurora stepped in and did great work leading the implementation of the new configuration in this release. She’s following this up with work on the future documentation and translation workflows. I’m excited to formally announce her role as a lead developer for VVV!

That’s all for 2.0.0. Thanks so much to all of our contributors and thank you for using VVV!

Varying Vagrant Vagrants 1.4.0

November 02, 2016

Hi! Welcome to the release post for Varying Vagrant Vagrants 1.4.0.

This release is packed with quite a bit of housekeeping. Let’s get that out of the way and then do a preview of what’s lined up for the future. You can also checkout the full changelog for more details.

First, VVV is now provisioned with PHP 7.0. PHP is on it’s 12th maintenance release after the initial stable 7.0, so there’s not much reason to keep waiting. This is a great way to test your code to make sure it is PHP 7 compatible.

NodeJS and NPM are a lot more organized and are positioned in a way to help clarify how we handle things in the future. First, we’ve decided to provide the latest LTS release of NodeJS. At this time, that’s 6.9.x, so that’s what VVV ships with. However, NVM is also installed during provisioning. This provides developers an easy way to switch between versions of NodeJS to work with the varying requirements of different libraries.

The “old” WordPress trunk repository, core.svn.wordpress.org, is no longer checked out during initial provisioning. VVV was created before WordPress switched to develop.svn.wordpress.org as the canonical source for development, so we’ve maintained that link throughout. At this point, it’s likely more confusing than anything else and adds more time to the provisioning process. If you have a current installation of VVV and make use of the wordpress-trunk directory, you’ll want to manage updates manually with svn up.

Those are the highlights. Much more detail exists in the CHANGELOG.

How about the future?

Releases

If I was going to phrase up the next year of VVV, I would say: Slow and steady with more minor releases.

I wrote the above in the VVV 1.3.0 release post back in February. It looks like about half was right—it was slow and steady, but there were no minor releases.

An ideal release schedule still looks to me like once a quarter, so I’m going to try and make that happen in 2017. Let’s target January 9th and April 10th for the next releases and see what happens.

Documentation

In August, the varyingvagrantvagrants.org site was converted to use Jekyll instead of WordPress. This felt slightly strange, because I love WordPress, but it does provide an easily managed GitHub based workflow to our documentation. Over the next year I’d like to see much more organized documentation via the VVV docs repository. Contributions to that are very much more than welcome!

New features

There are a few exciting tickets open right now that should shape VVV into something pretty cool. If all goes well in the next year, we should see the ability to switch PHP versions using PHPBrew, switch MySQL versions with MySQL Sandbox, and have much more control over the sites included with VVV by splitting them out into their own repositories.

That’s everything for 1.4.0. Thanks so much to all of our contributors and thank you for using VVV!

Varying Vagrant Vagrants 1.3.0

February 21, 2016

Howdy!

It’s time for another official release. VVV 1.3.0 has been tested and tagged and is waiting for you to grab it up. To read about all of the great things that make up this release, head over to the full changelog on GitHub.

A handful of highlights

Support for several new providers has been added. While VirtualBox is the most widely supported, we now account for Parallels, VMWare Fusion, VMWare Workstation, and Hyper-V in the default Vagrantfile. This is especially useful if you’re already using one of those to manage other virtual machines.

MailCatcher is now included as part of provisioning. An inbox view is available at vvv.dev:1080 to show you all of the mail sent by the virtual machine. This has been super helpful in troubleshooting issues with emails sent by core and plugins.

The WordPress core SVN repositories are now set to HTTPS. If these directories were originally provisioned as part of an old VVV configuration, it’s possible that things like svn up will show an error. You can use the svn relocate command to change the repository to the HTTPS URL. See issue 561 for more information. We’ll have a proper FAQ up to handle this at some point.

What's next?

If I was going to phrase up the next year of VVV, I would say: Slow and steady with more minor releases.

A tough thing about marking version numbers on a project like VVV is that all of the various versions of included packages change frequently. We need to do a better job of making it easier to maintain existing packages. I’d like to encourage more people to use the develop branch on GitHub and at the same time release more incremental versions. I’m going to start planning on a release every 3 months. We’ll see how that works and take it from there.

Major things I'd like to see

Update packages on vagrant provision, rather than only installing the first time. This should make vagrant provision a more common part of your daily workflow, used to keep things like PHP, Nginx, and MySQL updated.

Make it easy to remove default configurations. I think the Variable VVV project is an excellent way to add projects to VVV. We need a nice and simple way to turn off the default WordPress local, trunk, and dev environments provided by VVV.

Improved documentation. I’d like to follow the example of projects like WP-CLI, which has excellent documentation available in a nice, browsable format. Our GitHub wiki has a bunch of great information, but we can do better.

And be ready for...

A PHP upgrade. We’re sadly still on PHP 5.5.x and we should at least be on PHP 5.6.x if not PHP 7. Please leave feedback on issue #834 if you have a preference.

A switch in default domain names. Our domain.dev pattern is quickly looking like it will cause more issues with name collisions. Pay attention to issue #583 as we’ll use that to switch to domain.test or domain.localhost instead.

And that’s it. Thanks to all of our amazing contributors and thanks to everyone for using VVV!

Varying Vagrant Vagrants 1.2.0

December 15, 2014

Well hello. We’re finally here.

After a long 9 months of waiting, it’s a happy moment to push a tagged 1.2.0 release of Varying Vagrant Vagrants.

A full list of changes is available in the changelog. Here are some important ones.

First, VVV is now MIT Licensed. This is a big deal and we waited entirely too long as an open source project before choosing one. In fact, you could say we weren’t really an open source project at all until that point. Many many thanks to the near 50 contributors who were there to confirm their previous contributions as MIT so that we could proceed.

If there’s any lesson I learned from this, it’s to start with a license before anything else.

Ok, next. In new instances of VVV 1.2.0, database files are no longer mapped to a persistent local location. The database is entirely contained inside the virtual machine. What does this mean?

  • A full vagrant destroy and the removal of MySQL data from {vvv-dir}/database/data/ is recommended. While not necessary, this will keep a clean workflow in the future.
  • If database files already exist from an earlier version of VVV, data will continue to be mapped locally until removed. This is our attempt at backward compatibility. Anybody currently running VVV 1.1 may not even notice the change.
  • Even when not persistent locally, database data will continue to exist on the virtual machine through vagrant halt and vagrant suspend. This is the same behavior as a production server. You can restart the machine and the data remains.
  • Database data will no longer exist on the virtual machine after vagrant destroy. This is the same as reformatting a production server. At this point, the intention should be to start fresh or to restore from a backup.
  • A db_backup script is provided by default that creates local backups of each database on halt, suspend, and destroy if the vagrant-triggers plugin is installed. This is the current workflow, though we'll be taking steps to reduce the number of backups created in the future as well.

Somewhat more impactful is the change in operating system from Ubunto 12.04 LTS 32bit to 14.04 LTS 64bit. To upgrade from 1.1 to 1.2.0, a full vagrant destroy is likely necessary for best results. As mentioned above, your database data will be remain as it only becomes non-persistent on new instances of VVV and by choice on upgrade.

  • A new box will be downloaded for the base virtual machine. If you'd like to free space on your local machine, remove the old box with vagrant box remove precise32. Running vagrant box list will show you all base VMs on your local machine.
  • With a new operating system comes a new RSA key. If you are connecting via SSH through an application that relies on your machines known_hosts file, you will need to clear the old key for 192.168.50.4. See #365
  • I ran through the process of a 1.1 to 1.2.0 upgrade and left notes in this comment.

And other changes of note:

  • develop_git script is available inside the virtual machine to convert the default SVN WordPress checkouts to Git. With core accepting patches via pull request in the near future, this may be useful to some.
  • We're now tracking Nginx mainline, so expect that to be at the most current version during any provision.

And now the future! We have plenty of open issues and many goals to keep us busy, and I’m always interested in hearing new ideas for how VVV can best be used. Here’s what’s on the front burner.

  • Allow the selection of which sites to make active by default (See #474, #313, #210). It's great that we provide a handful of different WordPress instances by default, but it would sure be nice to disable the ones you don't use or to enable others you'd like to use. It would be really nice to separate some of the default configurations out into their own init scripts, similar to what Christian Foellmann has been working on in the new VVV multisite repository. This will also help out with projects like the WordPress Meta Environment, which really don't need the default sites at all.
  • And in the process of doing the above, provide some sort of configuration file. YAML seems easy, but eyes and ears are wide open for the best approach on this.
  • Now that we've worked out a license, we should work out what versioning really means to us. I would happily move to semantic versioning—hinted at with this release number—though it would be nice to cover thoughts on that. It would also be nice to work out a proper release schedule, so that we aren't all waiting 9 months for the next one. :)

That’s it, go get VVV 1.2.0 and have some fun. Thank you so much to the many, many contributors that have made VVV what it is today. And stop in with any questions, all are welcome!