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:

• A 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!

Edit this page