On Tue, 2005-08-16 at 08:50, Lance Lavandowska wrote: > I think we should avoid a blanket statement of "no db changes except > for major revisions" and instead opt for a concensus on changes. It > may be that a database change is warranted (to fix a particularly > grievious bug) in a minor version change.
So, I'm going to defend the opposite argument that we absolutely should be able to enforce "no db changes except on major versions." In my mind *if* we are a mature product then we should very seldomly need db changes and when we do need them we should group them together to make it easier on users. I don't see how our progress will be stunted by holding db changes to major releases. We already said that major releases are flexible, but would run roughly once every 3-4 months. So if we need 3.0 after 2.1 then fine, we do it. It's possible that our major rel numbers will go up faster, but again, we are supposed to be a mature product and that means our schema should be stable by now. I fully believe that we shouldn't need to change the schema more often than once every 3-4 months. If we do then we are just making things hard on our users and that sucks. That being said, I fully agree with Lance and Anil that group concensus should be the real determining factor when deciding about db updates. If we feel that a db change is truely needed then we do it. I don't want it to feel like our release plan is set in stone and cannot be changed. I think it is simply meant to be a guideline which lays out what we plan to do in most cases. -- Allen > > As in this case, the change is not warranted for immediate release. > Still, we may want to publish an Advisory to the wiki. Here we should > add a note to the MySql page that users of MySql 5 will want to run a > migration script and possibly replace some code (include as > attachments). And add a note to the bug report pointing to the > Advisory. > > That is all to say that we as a group should weigh any proposed db > change and in which future release it should be included. The goal > being to reduce the amount of work when upgrading to a new release. > > Lance
