History:Migration Guideline: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
(First Stab at the page (Imported from MoinMoin)) |
(intertwingle (Imported from MoinMoin)) |
||
| Line 10: | Line 10: | ||
<dd> |
<dd> |
||
Mean changes in the ''way'' data is stored in the database. A [[Style |
Mean changes in the ''way'' data is stored in the database. A [[Style Change|StyleChange]] like the [[Featuring Artist Style Alternative|FeaturingArtistStyleAlternative]] can have ''massive'' impacts on the structure of the data. If a client expects the old structure, it could fail working, just because of such a [[Soft Structure|SoftStructure]] change. |
||
</dl> |
</dl> |
||
Both kinds of change need to be tested extensively before becoming live/official. The difficulty with [[Soft Structure|SoftStructure]] changes, is that the consequences might |
Both kinds of change need to be tested extensively before becoming live/official. The difficulty with [[Soft Structure|SoftStructure]] changes, is that the consequences might lie far away (e.g. in the way the [[MusicBrainz Tagger|MusicBrainzTagger]] works) and are difficult to anticipate, let even to imagine. |
||
* Big [[Soft Structure|SoftStructure]] changes require [[Beta Editing|BetaEditing]]. This means that people apply a new [[Style Guideline|StyleGuideline]] to data on the [[Test Server|TestServer]], and try to use it. People should try to do controversial changes. This way we can find out about implications of the change before it goes live and does a lot of dammage. |
* Big [[Soft Structure|SoftStructure]] changes require [[Beta Editing|BetaEditing]]. This means that people apply a new [[Style Guideline|StyleGuideline]] to data on the [[Test Server|TestServer]], and try to use it. People should try to do controversial changes. This way we can find out about implications of the change before it goes live and does a lot of dammage. |
||
<ul><li style="list-style-type:none">There are special guidelines |
<ul><li style="list-style-type:none">There are special guidelines for [[Style Change|StyleChange]]<code><nowiki></nowiki></code>s: The [[Checklist For Style Changes|ChecklistForStyleChanges]] |
||
</ul> |
</ul> |
||
* [[Hard Structure|HardStructure]] changes require [[Beta Testing|BetaTesting]]. This means that the new sever software and database schema are loaded on the [[Test Server|TestServer]], and people try to find out whether thigs work, or if there are bugs left. Depending on the specific change, [[Beta Editing|BetaEditing]] might be required, too. |
* [[Hard Structure|HardStructure]] changes require [[Beta Testing|BetaTesting]]. This means that the new sever software and database schema are loaded on the [[Test Server|TestServer]], and people try to find out whether thigs work, or if there are bugs left. Depending on the specific change, [[Beta Editing|BetaEditing]] might be required, too. |
||
Revision as of 00:14, 2 February 2006
MusicBrainz Migration Guidelines
The MusicBrainz Migration Guidelines describe the process that is required for a change to get implemented on the server. These are currently (2005-12) under development and not compulsory yet
Changes can be devided into two categories: SoftStructure changes and HardStructure changes.
- Hard Structure Changes
-
Means actual changes to the DatabaseSchema. This does not need to be big. Changes in AdvancedRelationshipType
s and AdvancedRelationshipAttributes are already HardStructure. - Soft Structure Changes
- Mean changes in the way data is stored in the database. A StyleChange like the FeaturingArtistStyleAlternative can have massive impacts on the structure of the data. If a client expects the old structure, it could fail working, just because of such a SoftStructure change.
Both kinds of change need to be tested extensively before becoming live/official. The difficulty with SoftStructure changes, is that the consequences might lie far away (e.g. in the way the MusicBrainzTagger works) and are difficult to anticipate, let even to imagine.
- Big SoftStructure changes require BetaEditing. This means that people apply a new StyleGuideline to data on the TestServer, and try to use it. People should try to do controversial changes. This way we can find out about implications of the change before it goes live and does a lot of dammage.
- There are special guidelines for StyleChange
s: The ChecklistForStyleChanges
- HardStructure changes require BetaTesting. This means that the new sever software and database schema are loaded on the TestServer, and people try to find out whether thigs work, or if there are bugs left. Depending on the specific change, BetaEditing might be required, too.
- Finally the MetaBrainzCustomer
s need a TwoWeekMigrationPeriod for all HardStructure changes (actually this might exclude pure additions, so this might be rephrased to "for all Schema changes").
