Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I'm sorry, but you are missing the point. I never said 8.0.12 is perfect. But it serves a different purpose from 8.2.x and is the correct choice for an enterprise distro such as CentOS. The 8.0.x branch is the **stable** branch. It gets bug fixes and security fixes only, **not** new feature development. It is inherently more stable than the 8.2 branch. We choose to run CentOS, not Fedora, for our production systems specifically because it is an **enterprise distro** and we expect it to adhere to a release/update policy consistent with an enterprise distro. DRBD 8.2.x is where the bleeding edge feature development happens, and it is much more appropriate for Fedora or maybe for CentOSPlus. But IMHO, it does not belong in CentOS as the **only** DRBD option. On production systems, we cannot afford the risk inherent in upgrading such a mission-critical part of our deployment infrastructure (DRBD) to a version that is under active feature development. With every new feature added to DRBD 8.2, there is a higher probability of something breaking (i.e. regressions or new bugs appearing). This possibility is minimized in the 8.0.x branch. Clearly, the DRBD developers understand this or they would not offer two branches. >>But since currently they are the same protocol and that you can upgrade with yum upgrade to get the newer version without having to do anything more than you do to install 8.2 I am not sure what the problem is. (There is no more steps required to move to drbd82 that to upgrade drbd to 8.0.12) This is not a technical issue - it is a policy issue. Yes, technically an upgrade is possible. But that does not mean that it is the correct course of action. Those of us maintaining production systems have strict policies in effect pertaining to upgrades, for the purpose of maintaining stability and availability of our production systems. By forcing us to move from 8.0.x to 8.2.x, those policies are violated. An enterprise distro like CentOS is **not** supposed to make those types of policy decisions on behalf of its users. Thanks, Sam