Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the versioning system used by VVV #1050

Closed
jeremyfelt opened this issue Dec 13, 2016 · 2 comments · Fixed by Varying-Vagrant-Vagrants/varyingvagrantvagrants.org#126
Closed

Comments

@jeremyfelt
Copy link
Member

@jeremyfelt jeremyfelt commented Dec 13, 2016

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.

@GaryJones
Copy link
Contributor

@GaryJones GaryJones commented Dec 31, 2016

Those are sensible definitions.

With the first point at least, the documentation should include a reminder about what gets destroyed (i.e. which of our local client files are safe and which aren't) and what doesn't.

@lock
Copy link

@lock lock bot commented Feb 22, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants