1
0
Fork 0
mirror of https://github.com/ruby/ruby.git synced 2022-11-09 12:17:21 -05:00

* 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
This commit is contained in:
zzak 2014-01-20 04:57:31 +00:00
parent 5ecbe189af
commit dff0aa5a53
3 changed files with 18 additions and 14 deletions

View file

@ -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

View file

@ -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),

View file

@ -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: