[Maria-developers] Summary of discussion about MariaDB future and release plans
Hi, With all the european MariaDB people stuck in California, there is an unexpected opportunity for extra face-to-face meetups. So today I had the opportunity to enjoy lunch at a nice sushi place in Santa Clara with Henrik, Timour, Peter, Vadim, and Sanja. Here are a couple of key points from the discussion: 1. We need to consider carefully how we handle keeping the MariaDB product stable for production use. Peter had the point that the critical thing is avoiding behaviour change. This means that if some version of MariaDB works sufficiently different that the user need to work on their application to upgrade, it is a blocker to adoption. Different in this context means different from any previous version of MariaDB, but it _also_ means any difference from MySQL! I think I can see that this is actually more important than mere bugs/regressions. If a bug slips through, we can fix it, and if we can fix it quick enough the user may even be happy with us. But if the behaviour is qualitatively different (and such difference can not easily be turned off), that is a real problem for the user. We discussed a lot around this for the subquery optimisations. This is a "scary feature", as it has the very real potential to change execution plans, occasionally for the worse. As Timour pointed out, there is for each new optimiser feature a server variable to enable/disable it. So we need to very clearly state in the release notes, under "upgrading to MariaDB x.y", that there are optimiser changes, and give the exact list of variable settings that will make the optimiser run in "MySQL 5.1 mode". For other features this is simpler. For storage engines, just disable the engine and it will have no impact. For possibly replication plugins, again don't use the plugin and there should be no difference in behaviour. But again, we need to very carefully think about this and communicate/document this. For other features again we might need to re-think this point, making sure we do not change behaviour in a non reversible way. I think this is a good observation from those with a deep knowledge of the operational side of Databases. 2. On a note related to stability, I think we need to carefully avoid the mistakes from the MySQL release model. Basically, we need to have regular releases (6-12 month cycles). This is all-important! Much more important than any single feature, however big. We must _never_ push a feature into a tree if it is not ready. Better make an empty release! So this means it is actually wrong to say that subqueries will be in MariaDB 5.3. That should not be the plan. The subqueries will be in the first release made after they are ready. Which maybe 5.3, may be something else. I think we very nearly made the same mistake with 5.2. We had a feature list, and while some of them were "rolling", we also had features that were decided in advance that they _must_ be pushed at a certain date. I strongly believe this is wrong. We should have made _all_ features rolling. Unless we are extremely careful with this, sooner or later there will be sufficient pressure that we will push unfinished stuff into a release, causing _all_ of that release to be a failure. By waiting with the unfinished feature, only that feature will "fail", and by being careful with releases, the next release will be close anyway. (Yes, "finished" cannot mean bug free. But it can mean "as good as we can reasonably make it".) 3. The final point I took from the discussion was related to version numbering. We in the MariaDB team of course know that we rock, and that we will change the world tomorrow, or at least as soon as planes will take us back to Europe :-). But the reality is that for now, we are an appendix to MySQL with MariaDB 5.1 and 5.2. It thus can be argued that this should be reflected in the version numbering, to avoid confusion. Peter made the point that he would like to see MariaDB 5.1 and 5.2 versioning be made so that it is clear that there is a base MySQL version plus some well-defined set of changes. (This is how XtraDB release numbering works). So we currently have MariaDB 5.1.44, which is equivalent to MySQL 5.1.44 plus some set of safe patches. But MariaDB 5.2.0 is actually the same, just with some additional, also safe patches. So rather than go to MariaDB 5.2, we could imagine something like this: MariaDB 5.1.44-1 Current MariaDB 5.1.44 MariaDB 5.1.44-2 Current MariaDB 5.2.0 MariaDB 5.1.44-1.1 In case we need to do a bugfix for 5.1.44-1 MariaDB 5.1.46-1 Next time we merge MySQL 5.1.46 into MariaDB -1 MariaDB 5.1.46-2 Next time we merge MySQL 5.1.46 into MariaDB -2 I need to think more before I fully make up my mind about these points one way or the other, but I think these are in any case interesting points to consider. - Kristian.
Den 21-04-2010 00:29, Kristian Nielsen skrev:
2. On a note related to stability, I think we need to carefully avoid the mistakes from the MySQL release model. Basically, we need to have regular releases (6-12 month cycles). This is all-important! Much more important than any single feature, however big. We must_never_ push a feature into a tree if it is not ready. Better make an empty release! [...] We should have made_all_ features rolling.
I completely agree. I've always been a huge fan of the way other projects do this. They set a date for when a release will go out, and if a feature isn't ready by the start of the freeze period, it doesn't make it to the release. In theory this means there could be empty or irrelevant releases. But in practice, it actually does work. But people coming from closed source projects absolutely hate this kind of administration. To me, both ways are reasonable. You can either make a list of features that will go into a release and do the release when the features are done. Or you can set a date and release with the features that are ready at the time. I personally prefer the latter. And this is the one that best fit the release schedules of the Linux distros. The problem is that software managers try to do both, and that can't work. Of course, it's possible to balance the two approaches and mark some features as so important they can move the release dates, but I think this mostly just creates more confusion. Bo.
Hi Kristian Thanks for a good summary. I think my main, high-level takeaways were: I wasn't aware that even our optimizer work can be controlled by variables. I get for new features, but there's also refactoring going into 5.3. I guess we cannot guarantee 100% identical behavior with MySQL? One thing you didn't mention, but came up in this discussion as well as many others: The one killer feature people will be looking to MariaDB for will be the replication API, and promise of better replication. (more throughput, synchronous multi-master and easier to manage/failover). Subqueries will make MariaDB a better RDBMS, and possible a better migration target from the old proprietary databases, but replication is interesting to current install base - especially high profile users like Percona customers. On Wed, Apr 21, 2010 at 1:29 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
We discussed a lot around this for the subquery optimisations. This is a "scary feature", as it has the very real potential to change execution plans, occasionally for the worse.
As Timour pointed out, there is for each new optimiser feature a server variable to enable/disable it. So we need to very clearly state in the release notes, under "upgrading to MariaDB x.y", that there are optimiser changes, and give the exact list of variable settings that will make the optimiser run in "MySQL 5.1 mode". ...
2. On a note related to stability, I think we need to carefully avoid the mistakes from the MySQL release model. Basically, we need to have regular releases (6-12 month cycles). This is all-important! Much more important than any single feature, however big. We must _never_ push a feature into a tree if it is not ready. Better make an empty release!
So this means it is actually wrong to say that subqueries will be in MariaDB 5.3. That should not be the plan. The subqueries will be in the first release made after they are ready. Which maybe 5.3, may be something else.
I think we very nearly made the same mistake with 5.2. We had a feature list, and while some of them were "rolling", we also had features that were decided in advance that they _must_ be pushed at a certain date. I strongly believe this is wrong. We should have made _all_ features rolling.
I think everyone *says* they agree with above. You're right that we did drive 5.2 a bit differently. I think it is ok for us at MP to set some goals for ourselves as a team, then push to achieve those goals. But ultimately, if some feature is not ready in time (and even "in time" can often be a flexible concept as needed) then it will be dropped and considered for future releases. Btw, in the hypothetical case that we have nothing at all ready for a release, then there is no point in releasing every 6 months. So it is still valid to think of the process from the opposite point of view saying: This is the work we have in front of us now, we'll finish this, then we have a new release. Reading my own text below I guess I'm only saying that real life is often more flexible than just being one or the other. But ultimately - yes, we should do precisely what you describe.
3. The final point I took from the discussion was related to version numbering. We in the MariaDB team of course know that we rock, and that we will change the world tomorrow, or at least as soon as planes will take us back to Europe :-). But the reality is that for now, we are an appendix to MySQL with MariaDB 5.1 and 5.2.
It thus can be argued that this should be reflected in the version numbering, to avoid confusion. Peter made the point that he would like to see MariaDB 5.1 and 5.2 versioning be made so that it is clear that there is a base MySQL version plus some well-defined set of changes. (This is how XtraDB release numbering works).
So we currently have MariaDB 5.1.44, which is equivalent to MySQL 5.1.44 plus some set of safe patches. But MariaDB 5.2.0 is actually the same, just with some additional, also safe patches.
So rather than go to MariaDB 5.2, we could imagine something like this:
MariaDB 5.1.44-1 Current MariaDB 5.1.44 MariaDB 5.1.44-2 Current MariaDB 5.2.0 MariaDB 5.1.44-1.1 In case we need to do a bugfix for 5.1.44-1 MariaDB 5.1.46-1 Next time we merge MySQL 5.1.46 into MariaDB -1 MariaDB 5.1.46-2 Next time we merge MySQL 5.1.46 into MariaDB -2
I need to think more before I fully make up my mind about these points one way or the other, but I think these are in any case interesting points to consider.
This was an interesting remark by Peter. While I understand the point, and it is a valid point, I instinctively dislike the suggestions above. What we do for 5.1 is good. MariaDB 5.1.44 is based on MySQL 5.1.44. This is very easy to understand and remember. I do believe that having the same scheme for 5.2 is still an option: MariaDB 5.2.44 would be based on MySQL 5.1.44 (this is called 5.2.0 in reality). This is not as intuitive as it is for 5.1 series, but cleaner than what you suggest above. Con: this scheme will only work as long as MySQL keeps leaving holes in their releases. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc
Hi, Henrik! On May 05, Henrik Ingo wrote:
I think we very nearly made the same mistake with 5.2. We had a feature list, and while some of them were "rolling", we also had features that were decided in advance that they _must_ be pushed at a certain date. I strongly believe this is wrong. We should have made _all_ features rolling.
I think everyone *says* they agree with above.
Not everyone. I certainly disagree. I think there could be both "must have" and rolling features - unless there are "must have" features, you cannot promise anything to your customers, and they cannot plan their development. "All features are rolling" is as bad as "a release will be ready when it will be ready" - neither promises anything, and neither produces anything customers can rely upon.
You're right that we did drive 5.2 a bit differently.
And it worked quite well. The problem is not that there are "must have" feature, the problem (that MySQL was making every single release) that there are too many of them. We did not make this mistake in 5.2 and it worked out fine. In fact, it would've been much worse if all features were rolling - if they were, we'd release 5.2 in April 1st, as originally planned, and it would have only half the features it got, we would have no story for the Storage Engine Summit (and only vaporware for the plugin UC talk). But as plugin features were "must have" we delayed the release for one week, and they all made it in.
So rather than go to MariaDB 5.2, we could imagine something like this:
MariaDB 5.1.44-1 Current MariaDB 5.1.44 MariaDB 5.1.44-2 Current MariaDB 5.2.0 MariaDB 5.1.44-1.1 In case we need to do a bugfix for 5.1.44-1 MariaDB 5.1.46-1 Next time we merge MySQL 5.1.46 into MariaDB -1 MariaDB 5.1.46-2 Next time we merge MySQL 5.1.46 into MariaDB -2
That would be difficult. We cannot just make up any numbering scheme we want - it must fit into what distributions and various package managers expect from a version number. And as far as I understand, the usual expectations are - three numbers as a version, an optional suffix, and a local (distribution specific) revision number. I'm not sure the sufix is always significant, that is, I don't know how they treat two releases that have exactly the same version number, but different suffixes. In MySQL the suffix (-alpha, -beta) was not significant, and I don't remember if there was a reason for it or not. Regards, Sergei
Sergei, I just wanted to mention product version and how it is encoded in RPM and DEB packages are 2 different things. We have similar problem with Percona Server, adding some unstable features and we plan to either solve it by prefix or different repository. Inventing your own MariaDB 5.2 is very confusing, seriously Are fixes in MySQL 5.1.47 in MariaDB 5.2.0 ? Requirement to go and check the docs all the time is inconvenient. May be some time in the future amount of changes becomes so large the base MySQL version will not be relevant any more but it will take time.
We cannot just make up any numbering scheme we want - it must fit into what distributions and various package managers expect from a version number.
And as far as I understand, the usual expectations are - three numbers as a version, an optional suffix, and a local (distribution specific) revision number.
I'm not sure the sufix is always significant, that is, I don't know how they treat two releases that have exactly the same version number, but different suffixes. In MySQL the suffix (-alpha, -beta) was not significant, and I don't remember if there was a reason for it or not.
Regards, Sergei
-- Peter Zaitsev, CEO, Percona Inc. Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev 24/7 Emergency Line +1 888 401 3401 ext 911 Percona Training Workshops http://www.percona.com/training/
On Tue, May 11, 2010 at 3:39 AM, Peter Zaitsev <pz@percona.com> wrote:
Inventing your own MariaDB 5.2 is very confusing, seriously
Are fixes in MySQL 5.1.47 in MariaDB 5.2.0 ? Requirement to go and check the docs all the time is inconvenient.
What you say here is a very good use case to check proposals against. Your point apparently is, some of your customers may suffer from a bug and you know this was fixed in MySQL 5.1.47. Now it is helpful for you if you can automatically know which MariaDB, Percona Server versions the same fix will be found in. If it was called MariaDB 5.2.47, would this be any more helpful? Or are you insisting it must be MariaDB 5.1.47 (with possible 5.1, 5.2 or 5.3 type of differentiation appended to that with some tag, like mariadb-5.1.47_2nd_edition-...)
May be some time in the future amount of changes becomes so large the base MySQL version will not be relevant any more but it will take time.
Regarding bug fixes, we hope to stay in sync for some time to come, yes. We don't want to work on our own bugs, this is something we are happy to share :-) henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc
Hi Henrik, all On 11/05/2010, at 10:52 PM, Henrik Ingo wrote:
On Tue, May 11, 2010 at 3:39 AM, Peter Zaitsev <pz@percona.com> wrote:
Inventing your own MariaDB 5.2 is very confusing, seriously
Are fixes in MySQL 5.1.47 in MariaDB 5.2.0 ? Requirement to go and check the docs all the time is inconvenient.
What you say here is a very good use case to check proposals against. Your point apparently is, some of your customers may suffer from a bug and you know this was fixed in MySQL 5.1.47. Now it is helpful for you if you can automatically know which MariaDB, Percona Server versions the same fix will be found in.
If it was called MariaDB 5.2.47, would this be any more helpful?
I think *that* could actually work very well.
Or are you insisting it must be MariaDB 5.1.47 (with possible 5.1, 5.2 or 5.3 type of differentiation appended to that with some tag, like mariadb-5.1.47_2nd_edition-...)
If you keep the versioning exactly the same, upgrades can get into trouble and things can get very confusing for users on their systems. Full naming is not always visible from the command line. So having 5.2 vs 5.1 works optically as well as well it look like an upgrade from system tools perspective.
May be some time in the future amount of changes becomes so large the base MySQL version will not be relevant any more but it will take time.
Regarding bug fixes, we hope to stay in sync for some time to come, yes. We don't want to work on our own bugs, this is something we are happy to share :-)
Monty mentioned a monthly release cycle, and I think that might be key. Once people see that consistently happening, with useful fixes, chances are they don't worry about a few weeks delay on an SunOracle bugfix upstream getting into there. The consistency and reliability will be regarded as more important. Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org
Henrik, 5.2.47 is a lot more clear for me though it relays on the fact MySQL chose not to release 5.2 themselves What are you going to do with 5.5 as it comes out ? Create 5.6 and hope MySQL will never release such a version ? I think it is confusing. I also think this is moving away from what things really are MariaDB 5.2.0 is based on 5.1.44 (whatever) and it just includes more changes than MariaDB 5.1.44 There is also MariaDB 5.3 which also may be based on the same base MySQL version though have even more changes.
If it was called MariaDB 5.2.47, would this be any more helpful? Or are you insisting it must be MariaDB 5.1.47 (with possible 5.1, 5.2 or 5.3 type of differentiation appended to that with some tag, like mariadb-5.1.47_2nd_edition-...)
May be some time in the future amount of changes becomes so large the base MySQL version will not be relevant any more but it will take time.
Regarding bug fixes, we hope to stay in sync for some time to come, yes. We don't want to work on our own bugs, this is something we are happy to share :-)
henrik
-- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo <http://www.avoinelama.fi/%7Ehingo> book: www.openlife.cc
-- Peter Zaitsev, CEO, Percona Inc. Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev 24/7 Emergency Line +1 888 401 3401 ext 911 Percona Training Workshops http://www.percona.com/training/
Hi Peter On 12/05/2010, at 4:00 PM, Peter Zaitsev wrote:
5.2.47 is a lot more clear for me though it relays on the fact MySQL chose not to release 5.2 themselves What are you going to do with 5.5 as it comes out ? Create 5.6 and hope MySQL will never release such a version ? I think it is confusing.
I also think this is moving away from what things really are MariaDB 5.2.0 is based on 5.1.44 (whatever) and it just includes more changes than MariaDB 5.1.44 There is also MariaDB 5.3 which also may be based on the same base MySQL version though have even more changes.
Ehm what are you suggestion we use for versioning method? Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org
Arjen, I would suggest something like Maria 2-5.1.44 Maria 3-5.1.44 Maria Version should be preffix not suffix and full version in this case On Tue, May 11, 2010 at 11:03 PM, Arjen Lentz <arjen@openquery.com> wrote:
Hi Peter
On 12/05/2010, at 4:00 PM, Peter Zaitsev wrote:
5.2.47 is a lot more clear for me though it relays on the fact MySQL chose not to release 5.2 themselves What are you going to do with 5.5 as it comes out ? Create 5.6 and hope MySQL will never release such a version ? I think it is confusing.
I also think this is moving away from what things really are MariaDB 5.2.0 is based on 5.1.44 (whatever) and it just includes more changes than MariaDB 5.1.44 There is also MariaDB 5.3 which also may be based on the same base MySQL version though have even more changes.
Ehm what are you suggestion we use for versioning method?
Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget.
Follow our blog at http://openquery.com/blog/ OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org
-- Peter Zaitsev, CEO, Percona Inc. Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev 24/7 Emergency Line +1 888 401 3401 ext 911 Percona Training Workshops http://www.percona.com/training/
Hi!
"Peter" == Peter Zaitsev <pz@percona.com> writes:
Peter> Henrik, Peter> 5.2.47 is a lot more clear for me though it relays on the fact MySQL chose Peter> not to release 5.2 themselves Yes. Peter> What are you going to do with 5.5 as it comes out ? Create 5.6 and hope Peter> MySQL will never release such a version ? It depends on how fast MySQL 5.6 comes out. As this is 2+ years in the future, we don't have to concern ourselves with that now. We can always use something like MariaDB 5.5b.1, 5.5c.1. Peter> I think it is confusing. We don't have much choice just now than wait and see and do the best of it. Peter> I also think this is moving away from what things really are MariaDB 5.2.0 Peter> is based on 5.1.44 (whatever) and it just includes more changes than Peter> MariaDB 5.1.44 That has been true for every MySQL release ever now and will be in the future. You can also argue that MariaDB 5.1 is based on MySQL 5.0 + changes and because of that we should base the version numbers on 5.0 version numbers. What is important is that each different main release (5.1, 5.2 etc) have their own development phase and are thus independent releases. We will also keep each main version up to date for a long time (which is what distributions require nowadays). Peter> There is also MariaDB 5.3 which also may be based on the Peter> same base MySQL version though have even more changes. The right way to look at it is to say that MariaDB 5.3 is based on MariaDB 5.2. MariaDB 5.3 has also things from MySQL 5.1, 5.5 and 6.0 and things that is not in any MySQL version. Regards, Monty
Den 12-05-2010 21:04, Michael Widenius skrev:
>>>>> "Peter" == Peter Zaitsev<pz@percona.com> writes: Peter> Henrik, Peter> 5.2.47 is a lot more clear for me though it relays on the fact MySQL chose Peter> not to release 5.2 themselves
Yes.
Peter> What are you going to do with 5.5 as it comes out ? Create 5.6 and hope Peter> MySQL will never release such a version ?
It depends on how fast MySQL 5.6 comes out. As this is 2+ years in the future, we don't have to concern ourselves with that now.
We can always use something like MariaDB 5.5b.1, 5.5c.1.
It sounds like there will be a number problem no matter what we do. For example, we just had to release 5.1.44b, which is our second 5.1.44 based release. This means we have a line like 5.1.39, 5.1.42, 5.1.44, 5.1.44b, 5.1.46... That's awful as well, but it's bound to happen whenever we track the patch number of MySQL. You can't even assume that people understand that our 5.1.44 release includes the complete MySQL 5.1.44. This was *very* clear from talking to people that the MySQL conference. The version number does not tell people what we think it should. No matter what we do, there will be some problem with the version numbers, and some story to tell people. To me this says we should do something clean and simple. I would like to suggest going back to a version numbers scheme for 5.2 starting with 5.2.0 and increase the patch level on each release of it. We can add "Includes MySQL 5.1.46" on top of the download pages, the man pages, the help text and version number of the binary etc. If we try to get cute or clever with the version numbers, we will still fail to get a clean message across. It's impossible to fix this with a number sequence, so don't try. We should keep the version numbers as well as the story as simple as possible. I'm a big KISS fan. Bo.
Hi!
"Henrik" == Henrik Ingo <henrik.ingo@avoinelama.fi> writes:
Henrik> On Tue, May 11, 2010 at 3:39 AM, Peter Zaitsev <pz@percona.com> wrote:
Inventing your own MariaDB 5.2 is very confusing, seriously
Are fixes in MySQL 5.1.47 in MariaDB 5.2.0 ? Requirement to go and check the docs all the time is inconvenient.
Henrik> What you say here is a very good use case to check proposals against. Henrik> Your point apparently is, some of your customers may suffer from a bug Henrik> and you know this was fixed in MySQL 5.1.47. Now it is helpful for you Henrik> if you can automatically know which MariaDB, Percona Server versions Henrik> the same fix will be found in. Henrik> If it was called MariaDB 5.2.47, would this be any more helpful? Or Henrik> are you insisting it must be MariaDB 5.1.47 (with possible 5.1, 5.2 or Henrik> 5.3 type of differentiation appended to that with some tag, like Henrik> mariadb-5.1.47_2nd_edition-...) This wouldn't solve the problem with MySQL 5.5, which has exactly the same problems. Trying to keep same version number over different branches doesn't make much sence. I don't know of any project that has ever done. Regards, Monty
Hi!
"Peter" == Peter Zaitsev <pz@percona.com> writes:
Peter> Sergei, Peter> I just wanted to mention product version and how it is encoded in RPM and Peter> DEB packages are 2 different things. Peter> We have similar problem with Percona Server, adding some unstable features Peter> and we plan to either solve it by prefix or different repository. Peter> Inventing your own MariaDB 5.2 is very confusing, seriously Peter> Are fixes in MySQL 5.1.47 in MariaDB 5.2.0 ? Requirement to go and Peter> check the docs all the time is inconvenient. For the latest MariaDB 5.2, all the fixes in the latest MariaDB 5.1 are there. The game plan is to release both once a month (first 5.1 and then 5.2). That way you can always assume that 5.2 is up to date (at least for any bug that was fixed more than a month ago). This is not different from MySQL 5.0 or MySQL 5.1; You can always assume that when a new MySQL 5.1 is out, it includes all bug fixes from 5.0. Regards, Monty
Monty, For the latest MariaDB 5.2, all the fixes in the latest MariaDB 5.1
are there.
This does not really help as one has to often check this a while ago. Do you remember now what MySQL 5.0 bug fixes are included in MySQL 5.1.26 ? Finding what 5.0 version was last at that time and also acconting for "race" condition when they were both in the progress is not easy. But also it is a lot different topic. People see 5.0 and 5.1 as just different versions they are not compared.
The game plan is to release both once a month (first 5.1 and then 5.2). That way you can always assume that 5.2 is up to date (at least for any bug that was fixed more than a month ago).
This is not different from MySQL 5.0 or MySQL 5.1; You can always assume that when a new MySQL 5.1 is out, it includes all bug fixes from 5.0.
Regards, Monty
-- Peter Zaitsev, CEO, Percona Inc. Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev 24/7 Emergency Line +1 888 401 3401 ext 911 Percona Training Workshops http://www.percona.com/training/
Hi!
"Peter" == Peter Zaitsev <pz@percona.com> writes:
Peter> Monty, Peter> For the latest MariaDB 5.2, all the fixes in the latest MariaDB 5.1
are there.
Peter> This does not really help as one has to often check this a while ago. Peter> Do you remember now what MySQL 5.0 bug fixes are included in MySQL 5.1.26 Peter> ? One can trivially check that by doing one bzr command. I don't see this to be a big problem as most MySQL users have in the past shown a clear interest in getting releases more often and in that discussion it has never been seen as a problem when a fix from an earlier version is pushed up. Normally you can find that out trivially from the date the bug fix was pushed. If the server release date is notable higher than the approved bug fix, then the fix is in. Peter> Finding what 5.0 version was last at that time and also acconting for "race" Peter> condition when they were both in the progress is not easy. Peter> But also it is a lot different topic. People see 5.0 and 5.1 as just Peter> different versions they are not compared. Not true. If you have a problem with a bug you always have to think about releases as the bug is first fixed in the oldest releases and then slowly moved to newer releases. We have done this for 10+ years already and I can't remember a single email from anyone being concerned about this particular topic. (There are of course some people that may be concerned, but I doubt it's a significant % of our users). Regards, Monty
Monty, We're speaking about different MySQL users when. One I know about would not mix "trivial" and "bzr command" in the same sentence. Seriously if you're looking for mass market adoption you need to look at users not developers. You should not expect them to have any experience with bzr or even building software. My point is the broader adoption you want the more simple things should be for people to understand. I currently see it is not for a lot of people. Regarding bugs remember MariaDB is not MySQL - In MySQL bugs database I see the now the notes which change bug fixed in 5.0.55 and separate one 5.1.33, so I do not really need to try to compare anything here. With MariaDB I need to clearly know MySQL Baseline.
One can trivially check that by doing one bzr command.
I don't see this to be a big problem as most MySQL users have in the past shown a clear interest in getting releases more often and in that discussion it has never been seen as a problem when a fix from an earlier version is pushed up.
Normally you can find that out trivially from the date the bug fix was pushed. If the server release date is notable higher than the approved bug fix, then the fix is in.
Peter> Finding what 5.0 version was last at that time and also acconting for "race" Peter> condition when they were both in the progress is not easy. Peter> But also it is a lot different topic. People see 5.0 and 5.1 as just Peter> different versions they are not compared.
Not true. If you have a problem with a bug you always have to think about releases as the bug is first fixed in the oldest releases and then slowly moved to newer releases. We have done this for 10+ years already and I can't remember a single email from anyone being concerned about this particular topic.
(There are of course some people that may be concerned, but I doubt it's a significant % of our users).
Regards, Monty
-- Peter Zaitsev, CEO, Percona Inc. Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev 24/7 Emergency Line +1 888 401 3401 ext 911 Percona Training Workshops http://www.percona.com/training/
Hi all On 13/05/2010, at 4:03 AM, Peter Zaitsev wrote:
Monty, We're speaking about different MySQL users when. One I know about would not mix "trivial" and "bzr command" in the same sentence. Seriously if you're looking for mass market adoption you need to look at users not developers. You should not expect them to have any experience with bzr or even building software.
I'd concur with that.
My point is the broader adoption you want the more simple things should be for people to understand. I currently see it is not for a lot of people.
Regarding bugs remember MariaDB is not MySQL - In MySQL bugs database I see the now the notes which change bug fixed in 5.0.55 and separate one 5.1.33, so I do not really need to try to compare anything here. With MariaDB I need to clearly know MySQL Baseline.
Most people we deal with simply outsource that aspect as well now, i.e. they ask someone else or if they have an existing arrangement they trust their judgement. In that realm, relatively few people trawl through the MySQL changelogs. Even the SunOracle stuff is fairly extensive and somewhat confusing, particularly for people who don't deal with it in-depth on a daily basis (which is most). Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org
participants (7)
-
Arjen Lentz -
Bo Thorsen -
Henrik Ingo -
Kristian Nielsen -
Michael Widenius -
Peter Zaitsev -
Sergei Golubchik