travis 1.8.1.travis.704.5 → 1.8.1.travis.705.5

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    NzY5ZGEyOWQ5Zjg5ZDU5ZGE2NDhhODE2OGY0NGM5YTM4NGI4YjQ3MA==
+    NGUzZTMxNzU5N2U4ODUwNjgwMzgzMjI5MTZmMjhlMTNmYzkxM2U2Mw==
   data.tar.gz: !binary |-
-    NGNjYWRjNGZmYzJlNTUxYTFjZDhmNGM3M2QwMzIwNDgwMWU3OWU5OA==
+    MDBiNTc5NDA4OWU4MDFjNzM2ZjZiYmNjZWVhMTA5NmQ5OGQzMzg4OA==
 SHA512:
   metadata.gz: !binary |-
-    YWRkY2M4YjQ2NTZhMzcwNTU5Yjk5Nzk0MWIzY2M0ZmM1MDI2N2ZjYWY4OTVi
-    ZGU4MzI5M2JjMDkzZjFiYzRmMTQ3ZmZiMzM3OTgwOGFlZDBiNDEzZDk4NDM0
-    NDEwNjIzNDdhZTUxM2IyYmQxNWZiNTM4ZjNiZjRkYzUzNDE4NjI=
+    ODZhYTYxM2EzZjgyNTI3ZGNkNWI1ZTNhZmJjYjg1ODg3MGY2NGFiZGY5ZWYx
+    ZWY4OTY1NjYyYzgwOThkZWE2YTE3OTdlMGNiMzI4ZTE1OWI5ZDhhYjRiM2M1
+    NjNiM2ZhOTQxMTA4YmJlMDhjODQzZmViMDMyNGM0YmFkNmJjZDY=
   data.tar.gz: !binary |-
-    OTcyOWU0NDI0MGYxNWI4YjY4ZjcyODFkYTUxZmE4MjkyNzNiYThlOGY5OTYz
-    YWFiZDJhYTNlODNjZWRjMzZlYjY2Y2IyODU2Y2Q5NjVhNjhlZjllMWNiNGQy
-    NGQ1N2FjMDNlMTE3ZGRiN2ExZGY0OWMyNWZlNWM4ODYyOGI5YWE=
+    YzM0MjQxZDNmYWM0YTJiNjJkNmI4OGIxMTMwMWYwZjc2ZTE3ZDk2MzE3Zjc1
+    MmMwMjFmYjA3YzI3NjFlZjJkMjAzYTY5MGQ4ZDA5YWU0YTQ5OWNlMTkxZjIy
+    ZWEzMDlhZDY5ZDQ3ODE1MmUxYmM1Njk3ZjExYzg2NzljM2YwNmM=

data/README.md

@@ -1479,7 +1479,7 @@ puts "oh no" unless rails.green?
 
 For most parts, those are pretty much the same, the entities you get back look the same, etc, except one offers nice constants as part of the API, the other doesn't. In fact the "global" session style uses `Travis::Client` internally.
 
-So, which one to choose? The global style has one session, whereas with the client style, you have one session per client instance. Each session has it's own cache and identity map. This might matter for log running processes. If you use a new session for separate units of work, you can be pretty sure to not leak any objects. On the other hand using the constants or reusing the same session might save you from unnecessary HTTP requests.
+So, which one to choose? The global style has one session, whereas with the client style, you have one session per client instance. Each session has its own cache and identity map. This might matter for long running processes. If you use a new session for separate units of work, you can be pretty sure to not leak any objects. On the other hand using the constants or reusing the same session might save you from unnecessary HTTP requests.
 
 In either way, if you should use the first approach or long living clients, here is how you make sure not to have stale data around:
 
@@ -1597,7 +1597,7 @@ This is not something you should usually do, as partial loading is actually your
 
 #### Stateful Entities
 
-[Repositories](#repositories), [Builds](#builds) and [Jobs](#jobs) all are basically state machines, which means the implement the following methods:
+[Repositories](#repositories), [Builds](#builds) and [Jobs](#jobs) all are basically state machines, which means they implement the following methods:
 
 ``` ruby
 require 'travis'
@@ -1973,7 +1973,7 @@ Now make sure everything is working:
     $ travis version
     1.8.0
 
-See also [Note on Ubuntu](#note-on-ubuntu) below.
+See also [Note on Ubuntu](#ubuntu) below.
 
 ### Development Version
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: travis
 version: !ruby/object:Gem::Version
-  version: 1.8.1.travis.704.5
+  version: 1.8.1.travis.705.5
 platform: ruby
 authors:
 - Konstantin Haase