U:RDoc::NormalClass[iI" Version:ETI"Gem::Version;TI" Object;To:RDoc::Markup::Document: @parts[o;;[ :
@fileI" lib/rubygems/requirement.rb;T:0@omit_headings_from_table_of_contents_below0o;;[;o: RDoc::Markup::Paragraph;[ I"AThe Version class processes string versions into comparable ;TI"Evalues. A version string should normally be a series of numbers ;TI"Fseparated by periods. Each part (digits separated by periods) is ;TI"Gconsidered its own number, and these are used for sorting. So for ;TI"Finstance, 3.10 sorts higher than 3.2 because ten is greater than ;TI" two.;To: RDoc::Markup::BlankLine o; ;[
I"JIf any part contains letters (currently only a-z are supported) then ;TI"Gthat version is considered prerelease. Versions with a prerelease ;TI";part in the Nth part sort less than versions with N-1 ;TI"Hparts. Prerelease parts are sorted alphabetically using the normal ;TI"CRuby string sorting rules. If a prerelease part contains both ;TI"Cletters and numbers, it will be broken into multiple parts to ;TI"Fprovide expected sort behavior (1.0.a10 becomes 1.0.a.10, and is ;TI"greater than 1.0.a9).;T@o; ;[I"?Prereleases sort between real releases (newest to oldest):;T@o:RDoc::Markup::List:
@type: NUMBER: @items[ o:RDoc::Markup::ListItem: @label0;[o; ;[I"1.0;To;;0;[o; ;[I" 1.0.b1;To;;0;[o; ;[I" 1.0.a.2;To;;0;[o; ;[I"0.9;T@o; ;[I"QIf you want to specify a version restriction that includes both prereleases ;TI"Aand regular releases of the 1.x series this is the best way:;T@o:RDoc::Markup::Verbatim;[I"9s.add_dependency 'example', '>= 1.0.0.a', '< 2.0.0'
;T: @format0S:RDoc::Markup::Heading:
leveli: textI"How Software Changes;T@o; ;[ I"MUsers expect to be able to specify a version constraint that gives them ;TI"Osome reasonable expectation that new versions of a library will work with ;TI"Otheir software if the version constraint is true, and not work with their ;TI"Osoftware if the version constraint is false. In other words, the perfect ;TI"Nsystem will accept all compatible versions of the library and reject all ;TI"incompatible versions.;T@o; ;[I"LLibraries change in 3 ways (well, more than 3, but stay focused here!).;T@o;
;;;[o;;0;[o; ;[I"KThe change may be an implementation detail only and have no effect on ;TI"the client software.;To;;0;[o; ;[I"NThe change may add new features, but do so in a way that client software ;TI"7written to an earlier version is still compatible.;To;;0;[o; ;[I"MThe change may change the public interface of the library in such a way ;TI"/that old software is no longer compatible.;T@o; ;[I"PSome examples are appropriate at this point. Suppose I have a Stack class ;TI"=that supports a push and a pop method.;T@S;;i;I"$Examples of Category 1 changes:;T@o;
;: BULLET;[o;;0;[o; ;[I"FSwitch from an array based implementation to a linked-list based ;TI"implementation.;To;;0;[o; ;[I"KProvide an automatic (and transparent) backing store for large stacks.;T@S;;i;I"-Examples of Category 2 changes might be:;T@o;
;;;[o;;0;[o; ;[I"JAdd a depth method to return the current depth of the stack.;To;;0;[o; ;[I"NAdd a top method that returns the current top of stack (without ;TI"changing the stack).;To;;0;[o; ;[I"LChange push so that it returns the item pushed (previously it ;TI"!had no usable return value).;T@S;;i;I"-Examples of Category 3 changes might be:;T@o;
;;;[o;;0;[o; ;[I"MChanges pop so that it no longer returns a value (you must use ;TI"/top to get the top of the stack).;To;;0;[o; ;[I"DRename the methods to push_item and pop_item.;T@S;;i;I"!RubyGems Rational Versioning;T@o;
;;;[
o;;0;[o; ;[ I"MVersions shall be represented by three non-negative integers, separated ;TI"Iby periods (e.g. 3.1.4). The first integers is the "major" version ;TI"Mnumber, the second integer is the "minor" version number, and the third ;TI"#integer is the "build" number.;T@o;;0;[o; ;[I"JA category 1 change (implementation detail) will increment the build ;TI" number.;T@o;;0;[o; ;[I"IA category 2 change (backwards compatible) will increment the minor ;TI"/version number and reset the build number.;T@o;;0;[o; ;[I"NA category 3 change (incompatible) will increment the major build number ;TI"+and reset the minor and build numbers.;T@o;;0;[o; ;[ I"NAny "public" release of a gem should have a different version. Normally ;TI"Kthat means incrementing the build number. This means a developer can ;TI"Ngenerate builds all day long, but as soon as they make a public release, ;TI"!the version must be updated.;T@S;;i;I"
Examples;T@o; ;[I"OLet's work through a project lifecycle using our Stack example from above.;T@o;
;: NOTE;[ o;;[I"Version 0.0.1;T;[o; ;[I"(The initial Stack class is release.;To;;[I"Version 0.0.2;T;[o; ;[I"depth method.;To;;[I"Version 1.0.0;T;[o; ;[I"9Added top and made pop return nil ;TI"5(pop used to return the old top item).;To;;[I"Version 1.1.0;T;[o; ;[I"<push now returns the value pushed (it used it ;TI"return nil).;To;;[I"Version 1.1.1;T;[o; ;[I"3Fixed a bug in the linked list implementation.;To;;[I"Version 1.1.2;T;[o; ;[I",Fixed a bug introduced in the last fix.;T@o; ;[I"OClient A needs a stack with basic push/pop capability. They write to the ;TI"Roriginal interface (no top), so their version constraint looks like:;T@o;;[I"gem 'stack', '>= 0.0'
;T;0o; ;[I"NEssentially, any version is OK with Client A. An incompatible change to ;TI"Pthe library will cause them grief, but they are willing to take the chance ;TI"#(we call Client A optimistic).;T@o; ;[I"LClient B is just like Client A except for two things: (1) They use the ;TI"Adepth method and (2) they are worried about future ;TI"Iincompatibilities, so they write their version constraint like this:;T@o;;[I"gem 'stack', '~> 0.1'
;T;0o; ;[
I"PThe depth method was introduced in version 0.1.0, so that version ;TI"Oor anything later is fine, as long as the version stays below version 1.0 ;TI"Kwhere incompatibilities are introduced. We call Client B pessimistic ;TI"Pbecause they are worried about incompatible future changes (it is OK to be ;TI"pessimistic!).;T@S;;i;I"$Preventing Version Catastrophe:;T@o; ;[I"PFrom: http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html;T@o; ;[ I"GLet's say you're depending on the fnord gem version 2.y.z. If you ;TI"Jspecify your dependency as ">= 2.0.0" then, you're good, right? What ;TI"Fhappens if fnord 3.0 comes out and it isn't backwards compatible ;TI"Fwith 2.y.z? Your stuff will break as a result of using ">=". The ;TI"Nbetter route is to specify your dependency with an "approximate" version ;TI"Nspecifier ("~>"). They're a tad confusing, so here is how the dependency ;TI"specifiers work:;T@o;;[ I",Specification From ... To (exclusive)
;TI"%">= 3.0" 3.0 ... ∞
;TI"!"~> 3.0" 3.0 ... 4.0
;TI"!"~> 3.0.0" 3.0.0 ... 3.1
;TI"!"~> 3.5" 3.5 ... 4.0
;TI"!"~> 3.5.0" 3.5.0 ... 3.6
;TI"!"~> 3" 3.0 ... 4.0
;T;0o; ;[I"QFor the last example, single-digit versions are automatically extended with ;TI"&a zero to give a sensible result.;T; I" lib/rubygems/version.rb;T;
0; 0;
0[ [ [[I"Comparable;To;;[ ; @.;
0I" lib/rubygems/version.rb;T[[I"
class;T[[: public[[I"
correct?;F@6[I" create;F@6[I"new;T@6[:protected[ [: private[ [I"
instance;T[[;[[I"<=>;T@6[I" approximate_recommendation;F@6[I" bump;F@6[I" eql?;F@6[I"marshal_dump;F@6[I"marshal_load;F@6[I"prerelease?;F@6[I" release;F@6[I" to_s;F@6[I" version;F@6[;[[I"_segments;F@6[I"
_version;F@6[; [ [ [U:RDoc::Context::Section[i 0o;;[ ; 0;
0[@@.@.cRDoc::TopLevel