Hello Ignite community, Rolling upgrade (RU) support has been merged into master, but compatibility cannot be added to a release retroactively. The first upgrade needs something to test against; unless changes stay compatible starting today, there will be nothing.
We propose: 1. Adopt exact commit *3c6463f1ec2652eadd9493bc0823c988166490f2* as the provisional working RU baseline. - Unrelated to Ignite's baseline topology. - The marshalling rework is mostly merged here; the remainder is known ticket by ticket. - The build is stored unchanged with its SHA-256 digest; upgrade pairs test against exactly these bytes. - "Exact" means pinned to such a digest, not a version number. 2. Discipline: every RU-sensitive change merged after it MUST preserve mixed-version operation with the baseline; the only other way is path two below. RU-sensitive: alters what one node version sends to, or stores for, another. Preserving means one rule: during a rolling upgrade, *a new node pretends to be an old one to the rest of the cluster* - it sends and publishes nothing the baseline build cannot read. New behavior waits behind a feature gate (an in-code switch) until the upgrade is over - FINALIZATION. Local disk is free: an upgrade reads forward, and a BACKOUT (old-version nodes return while at least one still runs) wipes the directory before an old node comes back. 3. Each open wire or persistence ticket takes one of two paths. - *The author keeps it compatible with the baseline* - feature gate, dual path with both implementations, or deferral until the first fully tested upgrade pair ships; the default. - Or the community moves the baseline - a dedicated dev-list vote: consensus approval, at least three binding committer +1, no veto. Every upgrade edge (supported source->target path) is anchored before it is lost. No single pull request or company can move it. 4. Until the branch policy is approved, *a maintenance release carries only features backported from the main branch and MUST NOT create its own RU feature ID* (the number of one feature gate in the registry) - the same number would then gate different features on different builds. This vote decides: the baseline commit, the discipline above, the rule for moving the baseline later. A development baseline, not a production support claim. It does not decide: - The review bar for RU-sensitive changes - three committer +1 (author plus two independent) will be proposed in a separate thread. - The branch policy - a work item of the plan; returns to this list separately. - Supported pairs and profiles - each arrives with its qualifying phase. - Who does the work - estimates size it; taking an item is an ordinary contribution decision. - Any support claim to users - the first appears after one exact pair passes the claim gate. The full plan, with phases, procedures, and estimates: https://cwiki.apache.org/confluence/spaces/IGNITE/pages/446071769/IEP-132+Rolling+Upgrade+Readiness+Support+Policy+Test+Strategy+and+Roadmap A hands-on instruction for the first pair, for its administrator and tester, grows on the same page tree. The plan will keep moving. Please reply with disagreements or gaps. The [VOTE] thread with the same subject follows the discussion: consensus approval, *at least three binding committer +1, no vetoes, open for 72 hours*. Thanks!
