X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FDeploymentHandler%2FHandlesVersioning.pm;h=5ca2974da3043d0467537b773941527a9cb3a39a;hb=a976d6e46695d7015239ee4c30cb3708f4ce7942;hp=c8d4e79a52fa0d973c512f7841e3babb1d7bed15;hpb=e52174e31b95fe335f6ab8cfdbf23cc2a0c05673;p=dbsrgits%2FDBIx-Class-DeploymentHandler.git

diff --git a/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm b/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
index c8d4e79..5ca2974 100644
--- a/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
+++ b/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
@@ -1,7 +1,8 @@
 package DBIx::Class::DeploymentHandler::HandlesVersioning;
-use Moose::Role;
+use Moo::Role;
+
+# ABSTRACT: Interface for version methods
 
-# note: the sets returned need to match!
 requires 'next_version_set';
 requires 'previous_version_set';
 
@@ -14,14 +15,7 @@ __END__
 =head1 DESCRIPTION
 
 Typically a VersionHandler will take a C<to_version> and yeild an iterator of
-"version sets."
-
-A "version set" could be defined as:
-
- subtype 'Version', as 'Str';
- subtype 'VersionSet', as 'ArrayRef[Str]';
-
-and all a "version set" does is uniquely identify a migration.
+L<version sets|/VERSION SET>.
 
 Typically a call to a VersionHandler's L</next_version_set> with a C<db_version>
 of 1 and a C<to_version> of 5 will iterate over something like the following:
@@ -37,8 +31,8 @@ or maybe just
  [1, 5]
  undef
 
-Really how the version sets are arranged is up to the VersionHandler being
-used.
+Really how the L<version sets|/VERSION SET> are arranged is up to the
+VersionHandler being used.
 
 In some cases users will not want versions to have inherent "previous
 versions," which is why the version set is an C<ArrayRef>.  In those cases the
@@ -67,21 +61,21 @@ there is no inherent order for this type of database upgraded.
 
 =head2 Downgrades
 
-For the typical case I'd like downgrades to be easy for users to perform and
-understand.  That means that with the first two examples give above we can use
+For the typical case downgrades should be easy for users to perform and
+understand.  That means that with the first two examples given above we can use
 the L</previous_version_set> iterator to yeild the following:
 
 
  db_version = 5, to_version=1
- [4, 5]
- [3, 4]
- [2, 3]
- [1, 2]
+ [5, 4]
+ [4, 3]
+ [3, 2]
+ [2, 1]
  undef
 
 or maybe just
 
- [1, 5]
+ [5, 1]
  undef
 
 Note that we do not swap the version number order.  This allows us to remain
@@ -96,7 +90,7 @@ describes a version change, and not necesarily a defined progression.
  }
  print qq(\n);
 
-return an arrayref describing each version that needs to be
+Return a L<version set|/VERSION SET> describing each version that needs to be
 installed to upgrade to C<< $dh->to_version >>.
 
 =method previous_version_set
@@ -107,9 +101,18 @@ installed to upgrade to C<< $dh->to_version >>.
  }
  print qq(\n);
 
-return an arrayref describing each version that needs to be
+Return a L<version set|/VERSION SET> describing each version that needs to be
 "installed" to downgrade to C<< $dh->to_version >>.
 
+=head1 VERSION SET
+
+A version set could be defined as:
+
+ subtype 'Version', as 'Str';
+ subtype 'VersionSet', as 'ArrayRef[Str]';
+
+A version set should uniquely identify a migration.
+
 =head1 KNOWN IMPLEMENTATIONS
 
 =over