Upgrade terraform version to 0.0.9

[veenstra]

I burned through previous versions on our local gem server so I need to jump to 0.0.9.

[cespare]

Jack, if you're deploying an internal copy of a gem like that, you really need to do this under a different name. It doesn't make sense for the canonical version of the Terraform gem to have its version jump sporadically as dictated by our internal version numbering.

Much worse, if our internal gem server and Rubygems are both in a Gemfile, and Phil has pushed, say, v0.0.7, that will be a direct conflict with the v0.0.7 that lives on our internal server. The behavior there is not clear and will be extremely confusing for anyone trying to debug it.

So, for internal clones of gems, first put the source on our internal git repo, and then push internal gem versions only after you've edited the gemspec to change the version name. We do this for several other gems already.

I would recommend removing all divergent Terraform gems from our internal Gem server and then push up new gems under a new name. You will also need to track down any users of those versions and have them change their Gemfiles (but hopefully that's just your team).

[veenstra]

Yeah, sorry I messed up the versioning. I pushed the gem to our internal
server in order to test the end-to-end deploy. After a couple more changes
and some bug fixes, it wasn't long before I had burned through a few
version increments. But since this was still such an early release and not
many people are using it yet, I thought it would still be okay.

I will create a new gem "oo_terraform" (in a new internal git repo) and
push that to our internal gem server.

Jack

On Tue, Feb 5, 2013 at 3:14 PM, Caleb Spare [email protected]:

Jack, if you're deploying an internal copy of a gem like that, you really
need to do this under a different name. It doesn't make sense for the
canonical version of the Terraform gem to have its version jump
sporadically as dictated by our internal version numbering.

Much worse, if our internal gem server and Rubygems are both in a Gemfile,
and Phil has pushed, say, v0.0.7, that will be a direct conflict with the
v0.0.7 that lives on our internal server. The behavior there is not clear
and will be extremely confusing for anyone trying to debug it.

So, for internal clones of gems, first put the source on our internal git
repo, and then push internal gem versions only after you've edited the
gemspec to change the version name. We do this for several other gems
already.

I would recommend removing all divergent Terraform gems from our internal
Gem server and then push up new gems under a new name. You will also need
to track down any users of those versions and have them change their
Gemfiles (but hopefully that's just your team).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/14#issuecomment-13157971.

[cespare]

My point is that even pushing your own version to the internal gem server, even just for testing, is dangerous. Now anyone using Terraform at Ooyala can accidentally pick up this gem version without realizing it.

[cespare]

Also, may I suggest that we just put all Ooyala-related terraform changes in an Ooyala specific "plugin" gem? It's trivial to extend Terraform in your own code; no need for changes to go into Terraform core.

[veenstra]

That's a good suggestion. One of my commits, however, was a change to the core ensure_rbenv() method. And the other commit added a method that would probably be needed by anyone using rbenv and upgrading to a new version of Ruby.