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

Ship 1.2.0 #510

Closed
jeremyfelt opened this Issue Nov 21, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@jeremyfelt
Member

jeremyfelt commented Nov 21, 2014

We've been hanging in 1.1 land FOREVER. :) Mostly due to our licensing, which is lovingly figured out now. ❤️

I'd like to ship 1.2 this weekend. This doesn't mean too much, as we get plenty of new clones every day, so the master branch is one big test bed. It does mean we should get a few things in order.

  • Clone v1.1, vagrant up, checkout v1.2 - and see what happens. There will be breakage, as we changed operating systems. But we should have some kind of path to follow.
  • Clone master, vagrant up.
  • Check CHANGELOG
  • Check contributors in README

If anybody has other checklist items, chime away! 🎐

@jeremyfelt jeremyfelt added this to the 1.2 Release milestone Nov 21, 2014

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Nov 22, 2014

Just deleted VVV and the ubuntu/trusty64 box from my system and started over. Everything works as expected. It took 30 minutes, but it was downloading everything.

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Nov 22, 2014

Making some notes while I do the v1.1 to v1.2 check.

  • Clone VVV, checkout v1.1 tag
  • vagrant up works, though:
    • A 502 error first appeared because of php-fpm (see #363). Changed www.conf to match and default sites work fine.
    • The latest WordPress stable did not download (see #452). This is expected because of the old download method. Everything else works fine.
  • Backup any existing databases. VVV 1.2 allows you to remove persistent DB backups, which is nicer.
    • vagrant ssh
    • vagrant@vvv:~$ mysqldump wordpress_develop > /srv/database/backups/wordpress_develop.sql
    • vagrant@vvv:~$ mysqldump wordpress_trunk > /srv/database/backups/wordpress_trunk.sql
  • vagrant destroy
  • Checkout master (v1.2 tag soon).
  • Decide how to handle databases.
    • If you leave database/data/mysql_upgrade_info in your VVV directory, the data directory will continue to map. (Not recommended)
    • If you delete everything in the data directory, databases will persist inside the VM until it is destroyed. If you have the Vagrant Triggers plugin installed, databases will automatically backup on every vagrant halt, vagrant suspend, or vagrant destroy. You will want to leave readme.txt here as that is part of the repository.
    • Databases inside data/backups will continue to import if necessary during provisioning.
  • Update VVV to master or v1.2 tag.
  • vagrant up

And all is wonderful. Nice. I really did not expect it to go this well. :)

@EHLOVader

This comment has been minimized.

Contributor

EHLOVader commented Nov 24, 2014

Just curious. If you are going through a box change in 1.2, so there isn't a direct upgrade path from 1.1 couldn't this be an opportunity to actually implement pr#460 which was closed because it would likely result in some issues with the existing naming of the running machines?

@cfoellmann

This comment has been minimized.

Member

cfoellmann commented Nov 24, 2014

That would make some things a lot easier. Since most people use the master and VVV is in constant flux the 1.2 tag might not be a milestone that would smooth such a transition over

@EHLOVader

This comment has been minimized.

Contributor

EHLOVader commented Nov 24, 2014

I just noticed it is kind of in there. You just did config.vm.hostname.

I did

  config.vm.define "vvv" do |v|
  end

and

  config.vm.provider :virtualbox do |v|
    v.customize ["modifyvm", :id, "--memory", 1024]
    v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
    v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
    v.name = "vvv"
  end

Two methods which I had originally found via SO which wasn't actually any clearer.

I will check to see if there are any points where your hostname fails to replace the default. I had also thought of perhaps reading the parent directory for naming the hostname. It would be dynamic and hopefully prevent collisions by allowing multiple vvvs on a single host by using different directory names.

Update: Read through the commit history for that line and realized it isn't related to what I had done. Still I would be curious if a 1.2 release with a change as large as the box might be a possible point to merge my pull request. I updated it with PR 512 which uses the folder name so even multiple instances of vvv could exist if they were in differently named folders.

jeremyfelt added a commit that referenced this issue Dec 15, 2014

@jeremyfelt jeremyfelt self-assigned this Dec 15, 2014

@jeremyfelt jeremyfelt removed the in progress label Dec 15, 2014

jb510 added a commit to jb510/VVV that referenced this issue Feb 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment