Michael Häusler <[EMAIL PROTECTED]> said: > So it is lurker-time! Well let me chime in.
Thanks to all of you guys for bringing up fresh opinions and points of view. > Sumbry, Simon, I have to disagree with both of you. > In one line: Release early, release often. This is a good motto, but must be tempered with a certain discipline; releases need to remain stable, and upgrades need to make sense. Just throwing code out there is a bad idea, it needs to pass at least a modicum of QA. On the discipline issue, I'm definitely twisting the rules by suggesting that, although we are nominally in a release candidate stage, we're not ready for a release and we need to make a number of fairly significant external changes. A few weeks ago I started acting like a new user, opening up a fresh DBMail and seeing if I could make sense of it, and failed. That's what prompted me to push for changes in our user interfaces (on the command line and in the database). > >> Especially something like table_prefixes (At least dbmail_*). In a > >> day and age where everyone is moving everything into the database, > >> not prefixing the tables would instantly put dbmail at a huge > >> disadvantage > > This whole discussion about prefixes seems awfully trivial to me. > This is just a matter of personal preference. I personally rely on > schemas for separating namespaces (i.e. dbmail.* (Postgres supports this > now)). Introducing prefixes would break my installation. But I would > not complain, if they would be introduced in 2.0, and I would not > complain if they would be introduced in 2.1. This is simply a thing, > which you can't get right for everyone. > This has to be decided somehow. But imho, it should not be a showstopper > for a release, simply because we don't want to come to a decision. I'm not familiar with namespace schemas, is this something that we should be mentioning in our documentation or otherwise making use of? (note that it would have to be query-compatible with MySQL and others) I do realize that it's almost as much personal preference as it is prudent database management (at least in the open source world, where we often have the tables of many projects together in a single database), but I believe that the balance of issues weighs towards adding prefixes sooner rather than later. > > I've been a longtime lurker as well, and am running 1.2.6 in > > production awaiting a stable 2.0 release. I would far prefer to see > > all the invasive changes introduced with the 2.0 release rather than > > having to migrate again to 2.1 or 3.0. > Is this only about prefixes? I don't see any other thing, which would > destabilize the 2.x branch. I believe that we can find a solution for > this prefix-issue now. Maybe not a solution, which is optimal for all > cases, but a solution, everyone can live with. My position is essentially along these lines. Prefixes are very, very good for a large number of people, inconvenient for a small number, and a big problem for a handful. Those with big problems adapting to prefixes will have those same big problems a year from now when we definitely add prefixes, perhaps even worse problems if they have written code that interfaces directly with DBMail's tables, and which will be in more widespread use a year hence. > >> Point releases are maintennance releases. People will expect > >> regular maintennance releases, however the initial release of a new > >> version should contain most of the drastic changes that have been > >> discussed on this list for the past couple of months. > > Again, this is just a matter of preference. > Would you call the release of Linux kernel 2.6 a maintenance release? > > The developers are putting hard work into dbmail 2 for almost a year > now. I think the community of dbmail users eagerly awaits a 2.0 release > with all these improvements. I personally do not want to wait for a > bunch of *new* features to be implemented. I fear that dbmail has > already lost users in all these months, because it could not provide a > new "feature release". It is a short-lived business. I very much agree -- we're not going to be able to fit everything we want for 2.x into 2.0. The point releases will all be at the micro level, with 2.0.y for bug fixes, 2.x for added features and 2.x.y for bug fixes thereafter. That said, it is critical that we "set ourselves up for success" -- so my biggest project during the past two weeks was completely rewriting the command line processing for every one of the DBMail binaries, and rewriting the man pages to match them. Yet there's been perhaps two posts about that. But the table prefixes have caused shouts of grief and anger. I'm confused. With respect to the Linux kernel, it is actually the ABI which is the major version. If you compile something under Linux 1.x, it absolutely will not run on Linux 2.x. If you compile something under Linux 2.0, it will most likely run without a hitch on 2.2, 2.4 and 2.6. This is because the common binary interfaces to the kernel changed between 1.x and 2.x, but not between 2.x's. Aaron --
