[Pacemaker] Pre-Announce: End of 0.6 support is near

[Florian Haas]

On 2010-01-18 12:09, Andrew Beekhof wrote:
> On Mon, Jan 18, 2010 at 11:57 AM, Florian Haas <florian.haas at linbit.com> wrote:
>> On 2010-01-18 11:18, Andrew Beekhof wrote:
>>> Biggest caveat is the networking issue that makes pacemaker 1.0
>>> wire-incompatible with pacemaker 0.6 (and heartbeat 2.1.x).
>>> So rolling upgrades are out and you'd need to look at one of the other
>>> upgrade strategies.
>> Even though I've bugged you about this repeatedly in the past, I'll
>> reiterate that I think this non-support of rolling upgrades is a bad
>> thing(tm).
> 
> Its not something that was done intentionally, and we have tests in
> place to ensure it doesn't happen again.
> But given that to-date about 4 people have noticed it didn't work (and
> my employer has no interest in older versions especially when they're
> running heartbeat), I have no current inclination to spend time on the
> problem myself.
>
> That doesn't prevent the vocal minority that maintain its a huge issue
> affecting half the globe from fixing the problem instead of being a
> pests.  If you spent have as much time looking into the problem as
> moaning about it, it would probably be done by now.

Calm down. I thought one smiley face was enough to mark the post as at
least partially ironic.

Suggested course of action:

Remove this part:
"This method is currently broken between Pacemaker 0.6.x and 1.0.x
Measures have been put into place to ensure rolling upgrades always work
for versions after 1.0.0 If there is sufficient demand, the work to
repair 0.6 -> 1.0 compatibility will be carried out. Otherwise, please
try one of the other upgrade strategies. Detach/Reattach is a
particularly good option for most people."

from the "rolling upgrades" section in the docs, and declare that you
will only ever guarantee to support rolling upgrades within the same
minor release, and adjacent minor releases when the major release number
got bumped.

Then:
* Rolling upgrades would always be supported between 1.n.x and 1.n.y for
any value of n, x and y;
* Rolling upgrades would be always supported between 1.n.x and 1.n+1.0,
where x is the final bugfix release of the 1.n series;
* Any other upgrade paths would only be supported on a best-effort
basis, with detach/reattach as a readily available fallback option.

Just my two cents.
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100118/e3d0f951/attachment-0003.sig>