MOEN-45889: Fix update-dependency workflow release type detection

[kkgowtham-engg-sdk]

Summary

• update-bom.main.kts and update-ios-deps.main.kts always tagged the changelog bom/pod-version bump as [minor], regardless of the actual semver change.
• Added a determineReleaseType(oldVersion, newVersion) helper to both scripts that compares major/minor components of the old vs. new version and tags the entry [major], [minor], or [patch] accordingly.
• Updated the existing-entry regexes so re-runs correctly detect and replace entries tagged with any of the three release types, not just [minor].

Test plan

• Trigger the "Update Dependency" workflow with a patch-level android-bom bump and confirm changelog entries are tagged [patch].
• Trigger with a minor-level bump and confirm [minor].
• Trigger with a major-level bump and confirm [major].
• Confirm pre-release.main.kts picks up the correct release type from the tagged entries.

🤖 Generated with Claude Code

[moe-hodor]

🚪 Hodor is reviewing this PR... 👀

[moe-hodor]

💡 Suggestion — Handle downgrade case: The current logic returns "patch" when neither major nor minor components change, which is correct for patch bumps (1.2.3 → 1.2.4) or no change (1.2.3 → 1.2.3). However, if a downgrade occurs (1.2.3 → 1.2.2), this would incorrectly return "patch".

While downgrades shouldn't happen in practice (Maven Central versions only go up), consider adding explicit validation:

fun determineReleaseType(oldVersion: String, newVersion: String): String {
    val oldParts = oldVersion.split(".").map { it.toIntOrNull() ?: 0 }
    val newParts = newVersion.split(".").map { it.toIntOrNull() ?: 0 }
    val oldMajor = oldParts.getOrElse(0) { 0 }
    val oldMinor = oldParts.getOrElse(1) { 0 }
    val oldPatch = oldParts.getOrElse(2) { 0 }
    val newMajor = newParts.getOrElse(0) { 0 }
    val newMinor = newParts.getOrElse(1) { 0 }
    val newPatch = newParts.getOrElse(2) { 0 }
    
    return when {
        newMajor != oldMajor -> if (newMajor > oldMajor) "major" else error("Version downgrade detected")
        newMinor != oldMinor -> if (newMinor > oldMinor) "minor" else error("Version downgrade detected")
        newPatch != oldPatch -> if (newPatch > oldPatch) "patch" else error("Version downgrade detected")
        else -> error("No version change detected")
    }
}

This would catch configuration errors early. Not blocking since downgrades are unlikely, but improves robustness.

[moe-hodor]

💡 Suggestion — Same downgrade handling as Android script: The iOS version has the same potential downgrade edge case as the Android script. Consider applying the same validation improvement suggested in update-bom.main.kts for consistency. See the inline comment on line 148 of update-bom.main.kts for the suggested approach.

[moe-hodor]

Review Summary

Branching & CFR: patch/MOEN-45889_native_sdk_release_type_fix — category: patch, impact: Neutral CFR ✅

This PR fixes a bug in the dependency update automation scripts where BOM/pod version bumps were always tagged as [minor] in changelog entries, regardless of the actual semver change. The fix adds a determineReleaseType(oldVersion, newVersion) helper that correctly classifies changes as major/minor/patch by comparing version components, and updates the regex patterns to detect all three release type tags.

---

Quality Gates

✅ PR Size: 70 lines across 2 files — good size
ℹ️ Tests: No test files modified (automation scripts — manual verification via workflow runs)
✅ Migrations: None
✅ Duplication: determineReleaseType is duplicated across both scripts (acceptable for small utility functions in separate workflow scripts)

All checks passed. ✅

---

Issues Found

🔴 Critical: 0
⚠️ Warning: 0
💡 Suggestion: 1

---

Key Findings

Logic Quality: The semver comparison logic is correct. The function properly handles:

• Major/minor/patch version bumps
• Malformed versions (missing components default to 0)
• Non-numeric suffixes like -alpha (gracefully fall back to 0)

Regex Update: The regex patterns now correctly match all three release types [major], [minor], [patch] instead of only [minor], which was the root cause of re-run failures.

Integration: Verified that getReleaseTypeForModule in sdk-automation-scripts/scripts/common/utils.main.kts (lines 696-718) correctly parses these tags from CHANGELOG entries to determine release type.

---

What's Good

✅ Solves the stated bug — the release type will now correctly reflect the actual version change
✅ Logic is sound and handles edge cases well
✅ Backward compatible — existing [minor] entries still match the updated regex
✅ Consistent implementation across both Android (BOM) and iOS (pods) scripts

---

Verdict

The fix is solid. One minor suggestion about handling downgrade scenarios (which shouldn't occur in practice but would currently return "patch"). Otherwise, the logic correctly implements semver-based release type detection and integrates cleanly with the pre-release automation.

COMMENT — No blocking issues, ready to merge after optional improvement consideration.