Change Log

Subscribe with RSS to keep up with the latest changes.

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!

✎ Update Entry

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!

✎ Update Entry

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!

✎ Update Entry

Varying Vagrant Vagrants 1.2.0

December 14, 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:

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!

✎ Update Entry