Cookbook cleanup

diff --git a/lib/DBIx/Class/Manual/Cookbook.pod b/lib/DBIx/Class/Manual/Cookbook.pod
index 7d0de14..d265693 100644 (file)
--- a/lib/DBIx/Class/Manual/Cookbook.pod
+++ b/lib/DBIx/Class/Manual/Cookbook.pod
@@ -497,9 +497,6 @@ L<DBIx::Class> has now prefetched all matching data from the C<artist> table,
 so no additional SQL statements are executed. You now have a much more
 efficient query.
 
-Note that as of L<DBIx::Class> 0.05999_01, C<prefetch> I<can> be used with
-C<has_many> relationships.
-
 Also note that C<prefetch> should only be used when you know you will
 definitely use data from a related table. Pre-fetching related tables when you
 only need columns from the main table will make performance worse!
@@ -617,7 +614,7 @@ CD and Concert, and join CD to LinerNotes:
 
 =head2 Multi-step prefetch
 
-From 0.04999_05 onwards, C<prefetch> can be nested more than one relationship
+C<prefetch> can be nested more than one relationship
 deep using the same syntax as a multi-step join:
 
   my $rs = $schema->resultset('Tag')->search(
@@ -657,8 +654,7 @@ method.
 
 AKA getting last_insert_id
 
-If you are using PK::Auto (which is a core component as of 0.07), this is 
-straightforward:
+Thanks to the core component PK::Auto, this is straightforward:
 
   my $foo = $rs->create(\%blah);
   # do more stuff