From: Jonathan C. <cra...@sn...> - 2003-02-17 18:32:53
|
On Mon, 17 Feb 2003, Steve Fischer wrote: > 1. we need to decide which version of the schema the public schema > browser points to. it seems to me that it must always point to the most > recent official version of the schema. at CBIL, this might mean we need > a db instance which is neither production nor development that houses > the official schema. Yes, this is definitely true. Since the current schema browser requires an installed GUS instance, we'll either have to solve the multiple GUS instances per Oracle instance problem, or perhaps set up a separate small Oracle instance. > 2. i am going to venture the following tentative definition of a bug: > - a correction to something we are already modelling > - does not introduce any new tables > - can it introduce new attributes? > - *does not require migrating data* I don't think this is the right approach. If the system does not perform according to its documented specifications (or, more informally, if it doesn't do what it's expected or supposed to), then there is a bug. The question of how much (and what kind) of work would be required to fix the bug is an entirely separate question (and one that I think should not have any bearing on whether the problem is in fact a bug.) A bug fix could potentially introduce new tables or attributes, or even require migrating data. It's very unlikely this would happen, but not impossible. And, once we institute the policy of testing plugins before doing a schema release, the problem of having to modify the schema because it doesn't support everything the plugins want to do should disappear. > 3. if we do go with such a bug notion, then which tracker do we use? > here is a proposal: > - all schema changes --bugs and features-- go to the schema feature > tracker (might have to rename it) > - after we release a version of the schema (including a patched > version, eg 3.0.1) we add a "group" to the tracker called, eg, "3.0.1 > (bug)" and any bugs against that version are tagged with that group > - after we release a version of the schema, we add a "group" for the > next version of the schema, eg "3.1". feature requests are tagged with > this group. ultimately, we decide as a team which requested features > are going to make it into the 3.1 release. any that don't are either > re-tagged with the next release "3.2" or maybe relegated to a "not > scheduled yet" group. Jonathan is responsible for making these changes > (expressing the consensus). Sounds good, except I would prefer to associate bugs with the version of the schema that *contains* the bug, not the version of the schema that--if released--will (hopefully) fix it. > 4. we develop a light-weight mechanism for "patching" an instance, ie, > the scripts that will surgically make the patch. these always work on > the most recent official version of the schema. eg, patch 3.0.7 is only > officially applicable to the 3.0.6 version of the schema Since we're incorporating the patch number into the version number system we've already developed, we don't need a separate system for the patch files; it will be the same as the system for the migration files. Patches will hopefully be less work than migrations, but that may not always be the case. If you download release 3.0.2 and want to get to 3.0.7, you have to apply the following patches/migration scripts: 3.0.2 -> 3.0.3 3.0.3 -> 3.0.4 3.0.4 -> 3.0.5 3.0.5 -> 3.0.6 3.0.6 -> 3.0.7 Basically I'm not sure what you mean by a "light-weight" patching mechanism; the mechanism we've talked about for migrating from one release to the next is already light-weight, in the sense that it does the minimum amount of work needed to get from one to the other. Jonathan |