[Pacemaker] Announce: Pacemaker 1.1.10 now available

[Andrew Beekhof]

On 08/08/2013, at 11:48 PM, Andrew Martin <amartin at xes-inc.com> wrote:

> ----- Original Message -----
>> From: "Andrew Beekhof" <andrew at beekhof.net>
>> To: "The Pacemaker cluster resource manager" <pacemaker at oss.clusterlabs.org>
>> Sent: Thursday, August 8, 2013 2:35:53 AM
>> Subject: Re: [Pacemaker] Announce: Pacemaker 1.1.10 now available
>> 
>> 
>> On 08/08/2013, at 5:13 PM, Vladislav Bogdanov <bubble at hoster-ok.com>
>> wrote:
>> 
>>> 26.07.2013 03:43, Andrew Beekhof wrote:
>>> 
>>> ...
>>> 
>>>> Release candidates for the next Pacemaker release (1.1.11) can be
>>>> expected some time around Novemeber.
>>> 
>>> Did you completely discard plan of releasing 2.0.0?
>> 
>> Short answer, yes.
>> We're just going to continue doing 1.1.x releases for the foreseeable
>> future.
>> 
>> 
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> 
>> Project Home: http://www.clusterlabs.org
>> Getting started:
>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>> 
> Andrew,
> 
> In that case, which releases should be considered very stable for production use?

1.1.x is what everyone should be using.

There are extensive tests (520+ for the policy engine alone) that are run every time we push to github for catching and preventing regressions.
RHEL ships it, SLES ships it... if you want a version that goes beyond what upstream provides (ie. backports and more testing), I'd suggest one of those two vendors[1].

The basic problem is that upstream simply doesn't have the manpower to manage the backporting and testing required for multiple release series.
That job is best left to enterprise distros (or large companies like NTT whose efforts are the only thing keeping 1.0.x alive).

If someone wanted to pick a 1.1.x release and commit to replicating NTT's efforts... that would not be discouraged.


[1] I would still recommend upstream releases over _rebuilds_ of RHEL or SLES or whoever:

1. Upstream hasn't got the bandwidth to re-diagnose and re-fix bugs in vendor specific releases of which we don't know all the details
2. Even if the fix is trivial and well known, there is no way for upstream to get it into the packages you're using

tl;dr - Use the releases supplied by whoever is providing you with support