From: Kern S. <ke...@si...> - 2011-02-13 14:38:11
|
On Sunday 13 February 2011 12.00:37 rst wrote: > Thank you for your prompt reply. I'll try to answer both Kern and > Randy in this message. > > To Kern: > > I thought bacula is developed for some specific version of mysql > and changing it could be very risky. That was the case 10 years ago, but since 5-6 years, both MySQL and PostgreSQL have been very stable for the features Bacula uses. We seldom find problems. What you are speaking about below (version 4.1.22...) for us are rather old versions -- I don't think they are even supported by MySQL any more. Regards, Kern > > > To Randy: > > > There are the following two types of incompatible changes: > > 1) "controlled" incompatible changes introduced by the mylql > software development team. I want to provide two examples > here: > > a) Some changes in version 4.1.23 are incompatible with > the 4.1.22 version of MySQL. > > http://dev.mysql.com/doc/refman/4.1/en/news-4-1-23.html > > b) Some changes in version 4.1.13 are not compatible > with 4.1.12 > > http://dev.mysql.com/doc/refman/4.1/en/news-4-1-13.html > > 2) This case is rare but not unusual and thus it must be taken > into account in case you need high reliability. > > There are incompatible changes created due to bug > corrections. Let's assume a feature F of mysql works well > but it has some bug that manifests in a predictible and > known manner. Bacula (or another potential user) of F can > decide to use the feature by learning how to avoid the > drawbacks introduced by the bug. In this such case, the > way bacula uses the feature F is dependent on the bug. > Thus, correcting the bug may be not a benefit for bacula. |