AzLocal.UpdateManagement v0.8.72 - pipeline-template polish (patch)

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/apply-updates-schedule-audit.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: apply-updates-schedule-audit
-# Step.3 - Apply-Updates Schedule Coverage Audit Pipeline
+# Step.03 - Apply-Updates Schedule Coverage Audit Pipeline
 # This pipeline runs the read-only Test-AzLocalApplyUpdatesScheduleCoverage advisor
 # weekly to detect drift between the cron schedule(s) in your apply-updates pipeline
 # YAML and the UpdateStartWindow tags that operators have placed on Azure Local clusters.
@@ -87,7 +87,7 @@ parameters:
     default: false
 
 variables:
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   REQUIRED_MODULE_VERSION: '${{ parameters.moduleVersion }}'
   reportsPath: '$(Build.ArtifactStagingDirectory)/reports'
   # v0.8.7 sideload advisor defaults. Override at the pipeline / variable-group

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/apply-updates.yml

@@ -1,8 +1,11 @@
 # AZLOCAL-PIPELINE-ID: apply-updates
-# Step.7 - Apply Updates to Azure Local Clusters
+# Step.07 - Apply Updates to Azure Local Clusters
 # This pipeline applies updates to clusters filtered by UpdateRing tag value
 
-# BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
+# Author guidance lives OUTSIDE the customise markers so module refreshes
+# (Update-AzLocalPipelineExample) can correct it; only the trigger directive
+# between the markers is preserved verbatim across module upgrades.
+#
 # PREFERRED PATTERN - drive automated update runs from a ring-aware
 # schedule file (config/apply-updates-schedule.yml by default),
 # not from per-window crons.
@@ -39,8 +42,10 @@
 #         include: [main]
 #       always: true
 #
-# Content between BEGIN/END markers is preserved by
-# Update-AzLocalPipelineExample across module upgrades.
+# Replace `trigger: none` between the BEGIN/END markers below with your
+# schedules: block. That region (and ONLY that region) is preserved verbatim
+# by Update-AzLocalPipelineExample across module upgrades.
+# BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
 trigger: none
 # END-AZLOCAL-CUSTOMIZE:schedule-triggers
 
@@ -115,7 +120,7 @@ variables:
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
   - name: GENERATED_AGAINST_MODULE_VERSION
-    value: '0.8.71'
+    value: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/assess-update-readiness.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: assess-update-readiness
-# Step.5 - Assess Update Readiness (Pre-flight go/no-go gate)
+# Step.05 - Assess Update Readiness (Pre-flight go/no-go gate)
 # --------------------------------------------------
 # Runs Get-AzLocalClusterUpdateReadiness and Test-AzLocalClusterHealth -BlockingOnly
 # against a target UpdateRing (or the whole fleet) BEFORE apply-updates.yml runs.
@@ -70,7 +70,7 @@ variables:
   # the version actually installed and to the latest on PSGallery, and emits a warning
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/authentication-test.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: authentication-test
-# Step.0 - Authentication Validation and Subscription Scope Report
+# Step.00 - Authentication Validation and Subscription Scope Report
 #
 # PURPOSE:
 #   Validates that the service connection (Workload Identity Federation), App Registration,
@@ -35,11 +35,11 @@
 #   - Pipeline artifact (auth-report) containing JUnit XML + subscriptions.json + .csv.
 #
 # HOW TO RUN (after the file is committed and the pipeline is imported):
-#   Pipelines -> Step.0 - Authentication Validation and Subscription Scope Report -> Run pipeline.
+#   Pipelines -> Step.00 - Authentication Validation and Subscription Scope Report -> Run pipeline.
 #
 # See Automation-Pipeline-Examples/README.md, section 5.2, for the full setup story.
 
-name: Step.0 - Authentication Validation and Subscription Scope Report
+name: Step.00 - Authentication Validation and Subscription Scope Report
 
 # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
 # Add or modify `schedules:` blocks here to enable cron-driven runs. Content
@@ -60,7 +60,7 @@ variables:
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
   - name: GENERATED_AGAINST_MODULE_VERSION
-    value: '0.8.71'
+    value: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/fleet-connectivity-status.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: fleet-connectivity-status
-# Step.4 - Fleet Connectivity Status Monitoring Pipeline
+# Step.04 - Fleet Connectivity Status Monitoring Pipeline
 # This pipeline surfaces network-connectivity issues across every Azure Local
 # cluster the service connection can read - four scopes in one pipeline:
 #
@@ -49,7 +49,7 @@
 
 # Pipeline display name carries the same Step.N - prefix as the filename so the
 # ADO pipelines list (sorts by `name:` field) lists pipelines in execution order.
-name: Step.4 - Fleet Connectivity Status
+name: Step.04 - Fleet Connectivity Status
 
 # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
 # Edits inside this block are preserved across Update-AzLocalPipelineExample
@@ -110,7 +110,7 @@ variables:
   # the version actually installed and to the latest on PSGallery, and emits a warning
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/fleet-health-status.yml

@@ -105,7 +105,7 @@ variables:
   # the version actually installed and to the latest on PSGallery, and emits a warning
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/fleet-update-status.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: fleet-update-status
-# Step.9 - Fleet Update Status Monitoring Pipeline
+# Step.09 - Fleet Update Status Monitoring Pipeline
 # This pipeline monitors update status across all Azure Local clusters and generates reports
 #
 # USE CASES:
@@ -93,7 +93,7 @@ variables:
   # the version actually installed and to the latest on PSGallery, and emits a warning
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/inventory-clusters.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: inventory-clusters
-# Step.1 - Inventory Azure Local Clusters
+# Step.01 - Inventory Azure Local Clusters
 # This pipeline queries all Azure Local clusters and exports inventory with UpdateRing tag status
 #
 # OUTPUT COLUMNS:
@@ -43,7 +43,7 @@ variables:
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
   - name: GENERATED_AGAINST_MODULE_VERSION
-    value: '0.8.71'
+    value: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/manage-updatering-tags.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: manage-updatering-tags
-# Step.2 - Manage UpdateRing Tags
+# Step.02 - Manage UpdateRing Tags
 # This pipeline creates or updates UpdateRing tags on Azure Local clusters from a CSV file
 #
 # WORKFLOW:
@@ -46,7 +46,7 @@ variables:
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
   - name: GENERATED_AGAINST_MODULE_VERSION
-    value: '0.8.71'
+    value: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/monitor-updates.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: monitor-updates
-# Step.8 - Monitor In-Flight Updates (Azure DevOps)
+# Step.08 - Monitor In-Flight Updates (Azure DevOps)
 # -----------------------------------------------------------
 # Reports clusters whose latest update run is currently in flight, with the
 # CURRENT STEP each cluster is on and the ELAPSED DURATION of the run. Built
@@ -84,7 +84,7 @@ parameters:
     default: ''
 
 variables:
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   REQUIRED_MODULE_VERSION: '${{ parameters.moduleVersion }}'
   reportsPath: '$(Build.ArtifactStagingDirectory)/reports'
 

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/sideload-updates.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: sideload-updates
-# Step.6 - Sideload Updates (Opt-in, on-prem self-hosted agent)
+# Step.06 - Sideload Updates (Opt-in, on-prem self-hosted agent)
 #
 # OPT-IN, OFF BY DEFAULT. This pipeline automates the on-prem sideloading of
 # Azure Local solution-update media for clusters that cannot pull updates from
@@ -79,7 +79,7 @@ variables:
   # the version actually installed and to the latest on PSGallery, and emits a warning
   # log if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): queue-time parameter > pipeline variable
   # 'REQUIRED_MODULE_VERSION' overridden at queue time > empty (latest).
@@ -103,7 +103,7 @@ variables:
 
 stages:
 - stage: Sideload
-  displayName: 'Step.6 - Sideload Updates (Opt-in)'
+  displayName: 'Step.06 - Sideload Updates (Opt-in)'
   # Master opt-in gate: do nothing unless SIDELOAD_UPDATES is explicitly 'true'.
   condition: eq(variables['SIDELOAD_UPDATES'], 'true')
   jobs:

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/apply-updates-schedule-audit.yml

@@ -31,7 +31,7 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the eight pipelines in execution order.
-name: Step.3 - Apply-Updates Schedule Coverage Audit
+name: Step.03 - Apply-Updates Schedule Coverage Audit
 
 on:
   # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
@@ -96,7 +96,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   REQUIRED_MODULE_VERSION: ${{ github.event.inputs.module_version || vars.REQUIRED_MODULE_VERSION || '' }}
   # v0.8.4 - opt this workflow into Node.js 24 for all JavaScript actions
   # (actions/checkout, actions/download-artifact, actions/upload-artifact,

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/apply-updates.yml

@@ -12,10 +12,9 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the eight pipelines in execution order.
-name: Step.7 - Apply Updates
+name: Step.07 - Apply Updates
 
 on:
-  # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
   # PREFERRED PATTERN - drive automated update runs from a ring-aware
   # schedule file (config/apply-updates-schedule.yml by default),
   # not from per-window crons.
@@ -45,8 +44,13 @@ on:
   # but ring resolution then defaults to the workflow_dispatch input default,
   # which is rarely what schedule-triggered runs actually want.
   #
-  # Content between BEGIN/END markers is preserved by
-  # Update-AzLocalPipelineExample across module upgrades.
+  # Add your schedule: cron block between the BEGIN/END markers below. That
+  # region (and ONLY that region) is preserved verbatim by
+  # Update-AzLocalPipelineExample across module upgrades - keep author guidance
+  # like the paths above OUTSIDE the markers so module refreshes can correct it.
+  # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
+  # (No schedule by default - this pipeline is workflow_dispatch-only until you
+  #  add a schedule: block here. See the guidance comments above.)
   # END-AZLOCAL-CUSTOMIZE:schedule-triggers
 
   workflow_dispatch:
@@ -131,7 +135,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): manual workflow_dispatch input >
   # repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/assess-update-readiness.yml

@@ -36,7 +36,7 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the eight pipelines in execution order.
-name: Step.5 - Assess Update Readiness
+name: Step.05 - Assess Update Readiness
 
 on:
   # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
@@ -72,7 +72,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): manual workflow_dispatch input >
   # repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/authentication-test.yml

@@ -1,5 +1,5 @@
 # AZLOCAL-PIPELINE-ID: authentication-test
-# Step.0 - Authentication Validation and Subscription Scope Report
+# Step.00 - Authentication Validation and Subscription Scope Report
 #
 # PURPOSE:
 #   Validates that the App Registration / federated credentials / GitHub secrets / RBAC
@@ -46,7 +46,7 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the eight pipelines in execution order.
-name: Step.0 - Authentication Validation and Subscription Scope Report
+name: Step.00 - Authentication Validation and Subscription Scope Report
 
 on:
   # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
@@ -79,7 +79,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): manual workflow_dispatch input >
   # repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/fleet-connectivity-status.yml

@@ -50,7 +50,7 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the pipelines in execution order.
-name: Step.4 - Fleet Connectivity Status
+name: Step.04 - Fleet Connectivity Status
 
 on:
   # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
@@ -116,7 +116,7 @@ env:
   # PSGallery, and emits a ::notice annotation if the YAML appears stale -
   # prompting you to refresh via Copy-AzLocalPipelineExample -Update. See
   # Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install
   # the latest, the default "fix-forward" behaviour): manual workflow_dispatch
   # input > repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/fleet-health-status.yml

@@ -116,7 +116,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): manual workflow_dispatch input >
   # repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/fleet-update-status.yml

@@ -24,7 +24,7 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the eight pipelines in execution order.
-name: Step.9 - Fleet Update Status
+name: Step.09 - Fleet Update Status
 
 on:
   # BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers
@@ -105,7 +105,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample -Update. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): manual workflow_dispatch input >
   # repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/inventory-clusters.yml

@@ -21,7 +21,7 @@
 # Workflow name carries the same Step.N - prefix as the filename so the GitHub
 # Actions sidebar (which sorts workflows alphabetically by this `name:` field)
 # lists the eight pipelines in execution order.
-name: Step.1 - Inventory Azure Local Clusters
+name: Step.01 - Inventory Azure Local Clusters
 
 on:
   workflow_dispatch:
@@ -48,7 +48,7 @@ env:
   # this to the version actually installed and to the latest on PSGallery, and emits a
   # ::notice annotation if the YAML appears stale - prompting you to refresh via
   # Copy-AzLocalPipelineExample. See Automation-Pipeline-Examples/README.md section 5.
-  GENERATED_AGAINST_MODULE_VERSION: '0.8.71'
+  GENERATED_AGAINST_MODULE_VERSION: '0.8.72'
   # Resolution order for the module version pin (leave all unset to install the latest,
   # which is the default "fix-forward" behaviour): manual workflow_dispatch input >
   # repository variable 'REQUIRED_MODULE_VERSION' > empty (latest).