| 44 | |
| 45 | This, however, requires you to specify exactly one app version that is to be used for a given workunit at the time when the work is generated. This migth not work in all cases, e.g. if you issue a new app version (possibly for a few platforms only) that is compatible to the previous one, but not to the pre-previous one, and you have still workunits for the oldest app version in the DB. |
| 46 | |
| 47 | == Plan Classes == |
| 48 | |
| 49 | So here's a fourth way using plan classes: |
| 50 | To the plan classes of the old app versiomn add |
| 51 | {{{ |
| 52 | <plan_class> |
| 53 | <name>apppc</name> |
| 54 | ... |
| 55 | <max_wu_id>12345</max_wu_id> |
| 56 | </plan_class> |
| 57 | }}} |
| 58 | |
| 59 | Add a new plan class for the new app version(s) |
| 60 | {{{ |
| 61 | <plan_class> |
| 62 | <name>apppcNEW</name> |
| 63 | ... |
| 64 | <min_wu_id>12346</min_wu_id> |
| 65 | </plan_class> |
| 66 | }}} |
| 67 | |
| 68 | Workunits up to ID 12345 will be processed with app versions using the old plan class "apppc", workunits from ID 12346 on will be processed with app versions using the new plan class "apppcNEW". There exist similar tags to restrict plan classes to batches (<min_batch> and <max_batch>). |