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