@@ -10,12 +10,34 @@ The action walks the `directory` input (default: repo root) recursively and upda
 |---|---|
 | `pom.xml` (root) | `<version>` of the project itself |
 | `pom.xml` (all) | `<parent><version>` when the parent belongs to this project or is tracked in `versions` |
-| `pom.xml` (root **and** child modules) | `<properties>` entries whose key ends in `.version` when the project name is in `versions` |
+| `pom.xml` (root **and** child modules) | `<properties>` entries whose key ends in `.version` when the project name is in `versions`, unless [pinned](#pinning-a-property-with-releaserversion-check-off) |
 | `gradle.properties` | Bare `version=` key → `project-version`; `{prefix}Version=` keys → looked up in `versions` via camelCase→kebab-case conversion |
 | `build.gradle` / `build.gradle.kts` | `version = '...'` / `version = "..."` declaration → `project-version` |
 
 The following directories are always skipped: `.git`, `node_modules`, `target`, `build`, `.gradle`.
 
+### Pinning a property with `@releaser:version-check-off`
+
+A `<properties>` entry is left alone when it carries the marker the Jenkins releaser has always used, as a trailing comment on the same line:
+
+```xml
+<spring-cloud-function.version>4.3.6-SNAPSHOT</spring-cloud-function.version>
+<spring-cloud-stream.version>4.3.4</spring-cloud-stream.version><!-- @releaser:version-check-off -->
+```
+
+Here `spring-cloud-function.version` is bumped as usual and `spring-cloud-stream.version` is not.
+
+**This exists for dependency cycles inside a release train.** `spring-cloud-stream` builds against `spring-cloud-function`, and `spring-cloud-function`'s samples build against `spring-cloud-stream`. Pointing both at the other's snapshot is a cycle, so one side pins to a released version and says so in the pom.
+
+The marker is matched against the property it trails, not the file, so a pinned entry does not pin its neighbours. A pinned property is **reported in the log even though nothing changed** — a property deliberately left alone otherwise looks exactly like the bump quietly missing one:
+
+```
+Left alone in spring-cloud-function-samples/function-sample-cloudevent-stream/pom.xml
+(@releaser:version-check-off): spring-cloud-stream.version (pinned at 4.3.4)
+```
+
+It applies to `<properties>` entries only. A project's own `<version>` is not covered — an unreleasable project is expressed by leaving it out of the release train, not by a marker.
+
 ## Inputs
 
 | Name | Required | Default | Description |
 
@@ -11,6 +11,7 @@ const {
   replaceProjectVersion,
   replaceParentVersion,
   replacePropertyValue,
+  hasVersionCheckOff,
   updateGradlePropertiesContent,
   updateBuildGradleContent,
   camelToKebab,
@@ -113,6 +114,41 @@ describe('replaceParentVersion', () => {
   });
 });
 
+// ── hasVersionCheckOff ────────────────────────────────────────────────────────
+
+describe('hasVersionCheckOff', () => {
+  // the exact shape spring-cloud-function's sample poms use, where pinning matters because
+  // stream depends on function and function's samples depend on stream
+  const pinned = `<properties>
+		<spring-cloud-function.version>4.3.6-SNAPSHOT</spring-cloud-function.version>
+		<spring-cloud-stream.version>4.3.4</spring-cloud-stream.version><!-- @releaser:version-check-off -->
+</properties>`;
+
+  test('finds the marker on the property it trails', () => {
+    expect(hasVersionCheckOff(pinned, 'spring-cloud-stream.version')).toBe(true);
+  });
+
+  test('does not leak to a neighbouring property', () => {
+    expect(hasVersionCheckOff(pinned, 'spring-cloud-function.version')).toBe(false);
+  });
+
+  test('is false when the property carries no marker', () => {
+    const xml = '<spring-boot.version>3.2.2</spring-boot.version>';
+    expect(hasVersionCheckOff(xml, 'spring-boot.version')).toBe(false);
+  });
+
+  test('tolerates extra comment text around the marker', () => {
+    const xml = '<a.version>1</a.version> <!-- pinned, @releaser:version-check-off, see #123 -->';
+    expect(hasVersionCheckOff(xml, 'a.version')).toBe(true);
+  });
+
+  test('a marker elsewhere in the file does not pin an unrelated property', () => {
+    const xml = `<version>0.0.1-SNAPSHOT</version><!-- @releaser:version-check-off -->
+<b.version>2</b.version>`;
+    expect(hasVersionCheckOff(xml, 'b.version')).toBe(false);
+  });
+});
+
 // ── replacePropertyValue ──────────────────────────────────────────────────────
 
 describe('replacePropertyValue', () => {
 
@@ -28335,7 +28335,7 @@ async function run() {
 
       for (const file of pomFiles) {
         const isRoot = path.resolve(file) === path.resolve(rootPom);
-        const { changed, updatedProperties } = updatePomFile(
+        const { changed, updatedProperties, skippedProperties } = updatePomFile(
           file,
           isRoot,
           projectVersion,
@@ -28347,6 +28347,12 @@ async function run() {
         if (changed) {
           core.info(`Updated ${path.relative(directory, file)}: ${updatedProperties.join(', ')}`);
         }
+        // Reported even when nothing changed: a property left alone on purpose is the kind
+        // of thing that otherwise looks like the bump silently missing one.
+        if (skippedProperties.length) {
+          core.info(`Left alone in ${path.relative(directory, file)} ` +
+            `(@releaser:version-check-off): ${skippedProperties.join(', ')}`);
+        }
       }
     }
 
@@ -28537,13 +28543,14 @@ function updatePomFile(filePath, isRoot, projectVersion, versions, currentRootVe
   const content = fs.readFileSync(filePath, 'utf-8');
   let updated = content;
   const updatedProperties = [];
+  const skippedProperties = [];
 
   const parser = new XMLParser({ ignoreAttributes: false });
   const parsed = parser.parse(content);
   const project = parsed?.project;
 
   if (!project) {
-    return { changed: false, updatedProperties: [] };
+    return { changed: false, updatedProperties: [], skippedProperties: [] };
   }
 
   // 1. Update the project's own <version>, skipping the <parent> block.
@@ -28595,13 +28602,18 @@ function updatePomFile(filePath, isRoot, projectVersion, versions, currentRootVe
   }
 
   // 3. Update <properties> entries ending in .version that match the versions map.
-  //    This applies to ALL pom files — root and child modules alike.
+  //    This applies to ALL pom files — root and child modules alike, except any the pom
+  //    has opted out of with @releaser:version-check-off.
   const properties = project?.properties ?? {};
   for (const [key, currentValue] of Object.entries(properties)) {
     if (!key.endsWith('.version')) continue;
     const projectName = key.slice(0, -'.version'.length);
     const targetVersion = versions[projectName];
     if (targetVersion && String(currentValue) !== targetVersion) {
+      if (hasVersionCheckOff(updated, key)) {
+        skippedProperties.push(`${key} (pinned at ${currentValue})`);
+        continue;
+      }
       const prev = updated;
       updated = replacePropertyValue(updated, key, targetVersion);
       if (updated !== prev) {
@@ -28614,7 +28626,7 @@ function updatePomFile(filePath, isRoot, projectVersion, versions, currentRootVe
   if (changed) {
     fs.writeFileSync(filePath, updated, 'utf-8');
   }
-  return { changed, updatedProperties };
+  return { changed, updatedProperties, skippedProperties };
 }
 
 /**
@@ -28663,6 +28675,25 @@ function replaceParentVersion(xml, oldVersion, newVersion) {
  *
  * Exported for unit testing.
  */
+/**
+ * True when the pom has opted this property out of version management with the marker the
+ * Jenkins releaser has always used:
+ *
+ *   <spring-cloud-stream.version>4.3.4</spring-cloud-stream.version><!-- @releaser:version-check-off -->
+ *
+ * Needed where two projects in the same train depend on each other - spring-cloud-stream
+ * builds against spring-cloud-function and function's samples build against stream - because
+ * pointing both at the other's snapshot is a cycle. One side pins to a release and says so.
+ *
+ * Exported for unit testing.
+ */
+function hasVersionCheckOff(xml, propertyName) {
+  const escapedName = escapeRegex(propertyName);
+  return new RegExp(
+    `<${escapedName}>[^<]*<\\/${escapedName}>[ \\t]*<!--[^>]*@releaser:version-check-off[^>]*-->`
+  ).test(xml);
+}
+
 function replacePropertyValue(xml, propertyName, newVersion) {
   const escapedName = escapeRegex(propertyName);
   const regex = new RegExp(`(<${escapedName}>\\s*)([^<]*)(\\s*<\\/${escapedName}>)`);
@@ -28895,6 +28926,7 @@ module.exports = {
   replaceProjectVersion,
   replaceParentVersion,
   replacePropertyValue,
+  hasVersionCheckOff,
   updateGradlePropertiesContent,
   updateBuildGradleContent,
   findFiles,
 
@@ -110,7 +110,7 @@ async function run() {
 
       for (const file of pomFiles) {
         const isRoot = path.resolve(file) === path.resolve(rootPom);
-        const { changed, updatedProperties } = updatePomFile(
+        const { changed, updatedProperties, skippedProperties } = updatePomFile(
           file,
           isRoot,
           projectVersion,
@@ -122,6 +122,12 @@ async function run() {
         if (changed) {
           core.info(`Updated ${path.relative(directory, file)}: ${updatedProperties.join(', ')}`);
         }
+        // Reported even when nothing changed: a property left alone on purpose is the kind
+        // of thing that otherwise looks like the bump silently missing one.
+        if (skippedProperties.length) {
+          core.info(`Left alone in ${path.relative(directory, file)} ` +
+            `(@releaser:version-check-off): ${skippedProperties.join(', ')}`);
+        }
       }
     }
 
@@ -312,13 +318,14 @@ function updatePomFile(filePath, isRoot, projectVersion, versions, currentRootVe
   const content = fs.readFileSync(filePath, 'utf-8');
   let updated = content;
   const updatedProperties = [];
+  const skippedProperties = [];
 
   const parser = new XMLParser({ ignoreAttributes: false });
   const parsed = parser.parse(content);
   const project = parsed?.project;
 
   if (!project) {
-    return { changed: false, updatedProperties: [] };
+    return { changed: false, updatedProperties: [], skippedProperties: [] };
   }
 
   // 1. Update the project's own <version>, skipping the <parent> block.
@@ -370,13 +377,18 @@ function updatePomFile(filePath, isRoot, projectVersion, versions, currentRootVe
   }
 
   // 3. Update <properties> entries ending in .version that match the versions map.
-  //    This applies to ALL pom files — root and child modules alike.
+  //    This applies to ALL pom files — root and child modules alike, except any the pom
+  //    has opted out of with @releaser:version-check-off.
   const properties = project?.properties ?? {};
   for (const [key, currentValue] of Object.entries(properties)) {
     if (!key.endsWith('.version')) continue;
     const projectName = key.slice(0, -'.version'.length);
     const targetVersion = versions[projectName];
     if (targetVersion && String(currentValue) !== targetVersion) {
+      if (hasVersionCheckOff(updated, key)) {
+        skippedProperties.push(`${key} (pinned at ${currentValue})`);
+        continue;
+      }
       const prev = updated;
       updated = replacePropertyValue(updated, key, targetVersion);
       if (updated !== prev) {
@@ -389,7 +401,7 @@ function updatePomFile(filePath, isRoot, projectVersion, versions, currentRootVe
   if (changed) {
     fs.writeFileSync(filePath, updated, 'utf-8');
   }
-  return { changed, updatedProperties };
+  return { changed, updatedProperties, skippedProperties };
 }
 
 /**
@@ -438,6 +450,25 @@ function replaceParentVersion(xml, oldVersion, newVersion) {
  *
  * Exported for unit testing.
  */
+/**
+ * True when the pom has opted this property out of version management with the marker the
+ * Jenkins releaser has always used:
+ *
+ *   <spring-cloud-stream.version>4.3.4</spring-cloud-stream.version><!-- @releaser:version-check-off -->
+ *
+ * Needed where two projects in the same train depend on each other - spring-cloud-stream
+ * builds against spring-cloud-function and function's samples build against stream - because
+ * pointing both at the other's snapshot is a cycle. One side pins to a release and says so.
+ *
+ * Exported for unit testing.
+ */
+function hasVersionCheckOff(xml, propertyName) {
+  const escapedName = escapeRegex(propertyName);
+  return new RegExp(
+    `<${escapedName}>[^<]*<\\/${escapedName}>[ \\t]*<!--[^>]*@releaser:version-check-off[^>]*-->`
+  ).test(xml);
+}
+
 function replacePropertyValue(xml, propertyName, newVersion) {
   const escapedName = escapeRegex(propertyName);
   const regex = new RegExp(`(<${escapedName}>\\s*)([^<]*)(\\s*<\\/${escapedName}>)`);
@@ -670,6 +701,7 @@ module.exports = {
   replaceProjectVersion,
   replaceParentVersion,
   replacePropertyValue,
+  hasVersionCheckOff,
   updateGradlePropertiesContent,
   updateBuildGradleContent,
   findFiles,
 
@@ -264,6 +264,8 @@ If all three attempts fail, the step **records a status and exits 0** rather tha
 
 The `ls-remote` is checked the same way for a related reason. `--exit-code` exits **2** when the remote answered and has no such branch — a real answer, and the common one — while any other non-zero is a transport failure. Treating the two alike would skip the merge for a project whose release branch was there all along, bump it anyway, and call the run a success.
 
+**`already-merged` alongside `would-push` is not a contradiction.** The Merge column answers "did `release/<version>` need merging into `.x`", and the Push column answers "is there anything to push at all" — and the version bump is a commit in its own right. Most runs show exactly that pair, because the merge has usually happened already while the snapshot bump has not. `nothing-to-push` means the branch was already at the new versions too. The summary says so under the table.
+
 The merge commit and the version-bump commit go up in a **single push**: one CI run per project, and if anything fails in between, nothing is pushed and the branch is left untouched so the whole project can simply be re-run. The `release/<version>` branch is left in place, not deleted.
 
 ### CI and PR workflow files are preserved across the merge
 
@@ -3144,6 +3144,16 @@ jobs:
                 `${icon(r.pushStatus)} ${r.pushStatus} | ${dep} |`);
             }
             L.push('');
+            // The Merge and Push columns look like they disagree when a no-op merge sits next
+            // to a push - which is most runs, since the merge is usually already done and the
+            // bump usually is not. Saying what the push carries is cheaper than everyone
+            // working it out from the job log each time.
+            L.push('**Merge and Push answer different questions.** The merge commit and ' +
+              'the version bump go up together in a single push, so the Push column covers the ' +
+              'whole leg: `already-merged` next to `would-push` means the merge was a no-op and ' +
+              'the snapshot bump is what would be pushed, while `nothing-to-push` means the ' +
+              'branch already had both.');
+            L.push('');
 
             const restoredAny = mb.filter(r => r.restored);
             const autoAny = mb.filter(r => r.autoResolved);