Commit | Line | Data |
24794769 |
1 | package DBIx::Class::DeploymentHandler::HandlesVersioning; |
2 | use Moose::Role; |
3 | |
f344dd91 |
4 | # note: the sets returned need to match! |
24794769 |
5 | requires 'next_version_set'; |
f344dd91 |
6 | requires 'previous_version_set'; |
24794769 |
7 | |
24794769 |
8 | 1; |
9 | |
10 | __END__ |
11 | |
96ef97e5 |
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 | |
24794769 |
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 |