On Aug 16, 2008, at 4:11 AM, Martin MC Brown wrote: > > 5.0 to 5.1 is *NOT* a minor update, please don't class it as such.
Part here is just terminology. Versioning is called major.minor.micro, so any change in value of Y in version X.Y with X remaining constant is a Minor update. Now true, not every project follows that convention so "Minor" (by numbering) updates might contain smaller or greater change. Anyway, that part is just terminology. Now, the more interesting issue you're raising implicitly here is that you're saying 5.1 is a significant change from 5.0. This seems to contradict the draft spec which gives the impression 5.1 remains largely compatible and there is a simple update and existing clients will continue to work. Is 5.1 a more disruptive update than what has been communicated so far? > 5.1 is not replacing 5.0, it is going to co-exist with it, and they > will be treated as two completely separate packages. As such, I > think the current ARC is completely correct in its approach. Story so far has been that 5.1 is an easy upgrade and users are expected to promptly upgrade and 5.0 soon goes away (after a small coexistence window to allow for dependent components to upgrade). If 5.0 soon goes away, clearly it is being replaced by 5.1. If 5.0 and 5.1 are going to be treated as separate products both of which concurrently live on indefinitely (until some faraway EOSL date) that's a much more controversial proposal than the previous one. Do you expect to continue updating 5.0 series in parallel? (Lars has already said no, but you're now implying yes). From memory, the only precedent for treating a new version as a wholly new product was Apache1 vs. Apache2, both of which live on and continue to be maintained concurrently. There the changes and use cases were sufficiently different that it was justified (but even then, there's grumbling about it). Suggesting this approach for something as similar as MySQL 5.0 & 5.1 is unlikely to be well received. >> #1: Explain why the dtrace interfaces are Volatile. > > Because they are not (a) finalized and (b) in the MySQL 5.1 source > tree yet. I know. When I say "explain", I meant in the spec before submitting it. Most (probably all) other ARC reviewers do not follow webstack- discuss, so the spec needs to be self-contained for that audience. Just because it has been discussed here doesn't mean any of the reviewers know about it. > You will have to copy them over, because the database files in 5.0 > and 5.1 are in different directories. You can't have them in the > same directory and allow both version to co-exist. Yes, something to call out in the spec. It's part of the upgrade process. >> #3: Is 'mysql' (the CLI) linked from /usr/bin? That's the command >> everyone wants to run out of the box. > > No, again, I thought this was clear (and we had a long discussion > about it). We wont be creating symbolic links for 5.1 to the /usr/ > mysql base. % uname Linux % mysql -u root Welcome to the MySQL monitor. Commands end with ; or \g. [...] % uname SunOS %mysql -u root zsh: command not found: mysql [developer to self: "I'm going back to Linux where mysql works!"] One of the goals of Web Stack project is that everything needs to "just work" out of the box and the user experience needs to be better than Linux wherever possible, certainly not inferior. Since 'mysql' (the CLI) is such a common command line invocation tool, why should user experience on OpenSolaris be inferior to Linux here? If it truly and absolutely must be inferior to Linux, a paragraph in the ARC spec justifying why will be in order. Of course, the far better answer is to make it not inferior to Linux in the first place! ;-) > The *standard* /usr/bin/mysql currently in Solaris is actually > linked to /usr/sfw/bin, and is from the 4.0 version that should be > discontinued. Hm, I don't see /usr/bin/mysql link on nevada nor OpenSolaris? But if it is, that just seems worse. > True, the point we are trying to make is that 5.0 wont be a standard > component in an OpenSolaris release once we've given people time to > migrate, and 5.1 is GA (RSN). Which contradicts your own statement earlier that 5.1 does not replace 5.0 ;-) It can't both be a new component that doesn't replace 5.0 and an upgrade which is meant to take the place of 5.0. >> #5: Where can we find documentation for these dtrace probes? > > It will be in the standard MySQL manual - and yes, I'm writing those > too :)) Sure, but a reviewer might expect something (one liner is fine) in the functional spec (ARC spec) about them. Take a look at Ruby spec for one example (I can't look it up right now, IIRC it was ruby spec which had it). This is probably not a requirement but someone might ask so it's safer to document things up front.
