add missing newline for no-linenumber-change dzil

[dbsrgits/DBIx-Class-DeploymentHandler.git] / lib / DBIx / Class / DeploymentHandler / HandlesVersioning.pm

diff --git a/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm b/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
index 47690e6..87a4286 100644 (file)
--- a/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
+++ b/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
@@ -1,25 +1,22 @@
 package DBIx::Class::DeploymentHandler::HandlesVersioning;
+
 use Moose::Role;
 
-# note: the sets returned need to match!
+# ABSTRACT: Interface for version methods
+
 requires 'next_version_set';
 requires 'previous_version_set';
 
 1;
 
+# vim: ts=2 sw=2 expandtab
+
 __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:
@@ -35,8 +32,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
@@ -65,21 +62,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
@@ -94,7 +91,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
@@ -105,9 +102,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
@@ -126,6 +132,3 @@ L<DBIx::Class::DeploymentHandler::VersionHandler::ExplicitVersions>
 
 =back
 
-__END__
-
-vim: ts=2 sw=2 expandtab