We've (very) loosely followed a form of semver in our versioning thus far. It looks like we're going to be best off calling the next version of VVV 2.0.0 because of some larger architectural changes.
Backward compatibility is a strange thing in a provisioner / VM configuration such as this because there are so many variables at play. Vagrant versions, VirtualBox versions, major upgrades between PHP versions, etc... It's often possible to maintain a VM through an upgrade to VVV, but it's often cleaner to destroy the box and provision from scratch.
I think we should have a commitment to backward compatibility for many of the things that we provide as part of VVV, but that we should also be realistic when it comes to upgrade processes.
I chatted with @LoreleiAurora today and described this as what I thought would be a good guide to our semantic versioning:
- Major version numbers are bumped when
vagrant destroy, git pull ...., and vagrant up will yield the best results.
- Minor version numbers are bumped when
git pull and vagrant up --provision can be guaranteed to work.
- Patch version numbers are bumped for very minor changes, when a provision may not even be necessary.
This issue description should be cleaned up as part of the VVV documentation. This will be useful for and may even make sense as part of the documentation for #961.
We've (very) loosely followed a form of semver in our versioning thus far. It looks like we're going to be best off calling the next version of VVV 2.0.0 because of some larger architectural changes.
Backward compatibility is a strange thing in a provisioner / VM configuration such as this because there are so many variables at play. Vagrant versions, VirtualBox versions, major upgrades between PHP versions, etc... It's often possible to maintain a VM through an upgrade to VVV, but it's often cleaner to destroy the box and provision from scratch.
I think we should have a commitment to backward compatibility for many of the things that we provide as part of VVV, but that we should also be realistic when it comes to upgrade processes.
I chatted with @LoreleiAurora today and described this as what I thought would be a good guide to our semantic versioning:
vagrant destroy,git pull ...., andvagrant upwill yield the best results.git pullandvagrant up --provisioncan be guaranteed to work.This issue description should be cleaned up as part of the VVV documentation. This will be useful for and may even make sense as part of the documentation for #961.