initial pod docs
[dbsrgits/DBIx-Class-DeploymentHandler.git] / lib / DBIx / Class / DeploymentHandler / HandlesVersioning.pm
1 package DBIx::Class::DeploymentHandler::HandlesVersioning;
2 use Moose::Role;
3
4 # note: the sets returned need to match!
5 requires 'next_version_set';
6 requires 'previous_version_set';
7
8 1;
9
10 __END__
11
12 =method next_version_set
13
14  while (my $version_set = $versions->next_version_set) {
15    ...
16  }
17
18 =method previous_version_set
19
20  while (my $version_set = $versions->previous_version_set) {
21    ...
22  }
23
24 # normally a VersionHandler will take
25 # a to_version and yeild an iterator of
26 # "version sets" or something like that.
27 #
28 # A "version set" is basically an arrayref
29 # of "version numbers" (which we already know
30 # is vague as is.)  Typically an call to a
31 # VH w/ a db version of 1 and a "to_version"
32 # of 5 will iterate over something like this:
33 # [1, 2]
34 # [2, 3]
35 # [3, 4]
36 # [4, 5]
37 #
38 # Of course rob wants to be able to have dep
39 # management with his versions, so I *think* his
40 # would work like this:
41 #
42 # to_version = 7, db_version = 1
43 # [1]
44 # [5]
45 # [7]
46 #
47 # Because 7 depended on 5, 5 was installed first;
48 # note that this potentially never released module
49 # doesn't use version pairs, instead it just yeilds
50 # versions.  Version pairs are too much work for users
51 # to have to deal with in that sitation.  We may
52 # actually switch to this for other versioners.
53 #
54 # The upshot of all this is that the DeploymentMethod
55 # needs to be able to take an ArrayRef[VersionNumber],
56 # instead of just a pair of VersionNumber.
57 vim: ts=2 sw=2 expandtab