* lib/rubygems/version.rb: [DOC] Use gender-neutral pronouns [ci skip]

* lib/rubygems/security.rb: ditto


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@44661 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

ChangeLog

@@ -1,3 +1,8 @@
+Mon Jan 20 13:55:03 2014  Zachary Scott  <e@zzak.io>
+
+	* lib/rubygems/version.rb: [DOC] Use gender-neutral pronouns [ci skip]
+	* lib/rubygems/security.rb: ditto
+
 Sun Jan 19 06:38:48 2014  Benoit Daloze  <eregontp@gmail.com>
 
 	* compar.c (cmp_equal): warn for this release and still rescue

lib/rubygems/security.rb

@@ -120,11 +120,11 @@ end
 # * HighSecurity - Here's the bugger that got us into this mess.
 #   The HighSecurity policy is identical to the MediumSecurity policy,
 #   except that it does not allow unsigned gems.  A malicious user
-#   doesn't have a whole lot of options here; he can't modify the
-#   package contents without invalidating the signature, and he can't
+#   doesn't have a whole lot of options here; they can't modify the
+#   package contents without invalidating the signature, and they can't
 #   modify or remove signature or the signing certificate chain, or
 #   RubyGems will simply refuse to install the package.  Oh well, maybe
-#   he'll have better luck causing problems for CPAN users instead :).
+#   they'll have better luck causing problems for CPAN users instead :).
 #
 # The reason RubyGems refused to install your shiny new signed gem was because
 # it was from an untrusted source.  Well, your code is infallible (naturally),

lib/rubygems/version.rb

@@ -81,8 +81,8 @@
 #
 # * Any "public" release of a gem should have a different version.  Normally
 #   that means incrementing the build number.  This means a developer can
-#   generate builds all day long for himself, but as soon as he/she makes a
-#   public release, the version must be updated.
+#   generate builds all day long, but as soon as they make a public release,
+#   the version must be updated.
 #
 # === Examples
 #
@@ -99,26 +99,25 @@
 # Version 1.1.1:: Fixed a bug in the linked list implementation.
 # Version 1.1.2:: Fixed a bug introduced in the last fix.
 #
-# Client A needs a stack with basic push/pop capability.  He writes to the
-# original interface (no <tt>top</tt>), so his version constraint looks
-# like:
+# Client A needs a stack with basic push/pop capability.  They write to the
+# original interface (no <tt>top</tt>), so their version constraint looks like:
 #
 #   gem 'stack', '~> 0.0'
 #
 # Essentially, any version is OK with Client A.  An incompatible change to
-# the library will cause him grief, but he is willing to take the chance (we
-# call Client A optimistic).
+# the library will cause them grief, but they are willing to take the chance
+# (we call Client A optimistic).
 #
-# Client B is just like Client A except for two things: (1) He uses the
-# <tt>depth</tt> method and (2) he is worried about future
-# incompatibilities, so he writes his version constraint like this:
+# Client B is just like Client A except for two things: (1) They use the
+# <tt>depth</tt> method and (2) they are worried about future
+# incompatibilities, so they write their version constraint like this:
 #
 #   gem 'stack', '~> 0.1'
 #
 # The <tt>depth</tt> method was introduced in version 0.1.0, so that version
 # or anything later is fine, as long as the version stays below version 1.0
 # where incompatibilities are introduced.  We call Client B pessimistic
-# because he is worried about incompatible future changes (it is OK to be
+# because they are worried about incompatible future changes (it is OK to be
 # pessimistic!).
 #
 # == Preventing Version Catastrophe: