View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020351 | mantisbt | upgrade | public | 2015-12-06 21:03 | 2016-01-25 12:22 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.3.0-rc.1 | ||||
Summary | 0020351: Enable schema updates in more than one branch | ||||
Description | We currently can only change schema on a single branch due to having a single schema version. Should we have enable the ability to track specific schema change steps enabling us to add schema changes in 1.2.x even though we have already release 1.3.x releases (or pre-releases) with schema changes? See 0020340 for an example where this is needed. I would rather have the option to add a schema change whenever it makes sense or there is need a need to do so. | ||||
Tags | No tags attached. | ||||
Copying note from 0020340:0052040
Well, I would argue that a sequence number is an ID... Joke aside, I'm not seeing that much benefit of switching from a numeric, sequential ID to a string. I find it useful to have an ID which both identifies the upgrade step as well as where it belongs in the sequence. Furthermore, it would become complicated to identify which steps have been applied, when, and in which sequence. That being said, maybe the ID doesn't need to be strictly sequential. In other words, as an alternative to your suggestion, we could "reserve" a block of upgrade steps when we switch to a new major version, allowing more flexibility for required schema changes within a minor release. For example, an hypothetical 2.0.0 schema.php could look like this: Release marker: 1.3.0upgrade steps 202..219 are reserved for 1.3.x releases$g_upgrade[220] = [...] Release marker: 2.0.0The problem with this approach is that it would need some special processing to cover the following scenario :
|
|
@dregad, that is why I think we need a model that provides the following:
The order of defining the upgrade steps in schema.php (or array index) can provide 3 A step id and a table that tracks steps would be needed for 2. That is a model that we used in the past. count(upgrade_steps_table) == # of steps in schema.php would provide 1 |
|