Varying Vagrant Vagrants 1.3.0

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

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!