Hi, >> 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.
And in some cases hugely and patently untrue and not followed, but, as you say, that is largely terminology and semantics. > 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? Nope, it should be fully compatible. But to lower the description and classification of 5.1 as a 'minor' update does a huge disservice to the functionality and improvements in 5.1, and the developers who have worked on it. We can argue for hours whether 5.1 should really have been a 6.0 (and there are people who believe that), but I don't think that is relevant to this discussion. And to pick up on your main point here, significant changes dont have to mean incompatible ones. >> 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. Ultimately, yes, short term, no. I'd say you were over-specifying the semantics of the situation :) > 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). I implied no such thing. What I stated was that both 5.1 and 5.0 packages would co-exist. We are not replacing the contents of, or the actual packages of 5.0 with a version that includes a 5.1 MySQL, but providing an additional package that provides a 5.1 MySQL. At some future point, the 5.0 packages will be discontinued. I'd say that was very sensible. And just in case it still isn't clear: No, we will not provide an updated version of the 5.0 packages. > 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. Not what I'm suggesting. >>> #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. I'm sure Sunanda will be able to make that change. I'll leave the debate about whether the probable reviewers are not on this list for another time :) >> 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. We do call it out in the spec, see section 6 where the upgrade instructions, and the requirement to run the upgrade script and a pointer to the upgrade instructions in the documentation are already provided. I don't see any need to go into more detail in the ARC case, most end- users are unlikely to use the ARC case as their only source for upgrade information. > >>> #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! ;-) YMMV on which Linux installs it into such a global location, not all of them do, and not all of them follow even MySQL's standards for the location of the different MySQL components. Believe me, this causes our support engineers no end of problems. For those of us in the documentation team it causes headaches too, as we have to keep track of them all :( I came in to this process comparatively late, but ISTR we couldn't wholesale replace 4.0 with the 5.0 version because the 4.0 version was used by too many other packages in the original toolset, and in that situation, v4.0 to v5.0 wasn't as smooth a transition. The reasons for installing 5.0 where we did (And ergo why we didn't replace the 'standard' mysql client) were well documented in the 5.0 ARC case. > >> 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. Yep. >> 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. I don't think it's a contradiction. You've mentioned in this message the situation when moving from Apache 1.x to Apache 2.x, and I see a number of parallels between the Apache and MySQL situation. There will be nothing to stop anybody continuing to run the 5.0 packages, in the same way there is no reason why people can't continue to run the Apache 1.x packages, but that rather defeats the object of providing newer, updated, software, doesn't it? What we are *not* doing is forcing people to use 5.1 without allowing them to migrate first. > >>> #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. A one liner saying what? You couldn't describe the probes we are offering in one line, or even a paragraph. We already provide a list of the probes that we will be including in the spec. How much more detail do you want here? I guess we could add a line saying that there will be documentation. What we can't do is point them to it, since it doesn't exist yet :) MC -- Martin 'MC' Brown, mc at mcslp.com and mc at mysql.com Technical Writer, Database Group, Sun Microsystems Everything MCslp: http://planet.mcslp.com
