Skip to content

Add next_version parameter to release notes update actions#706

Merged
iangmaia merged 4 commits intotrunkfrom
iangmaia/fix-release-notes-version-bump
Mar 30, 2026
Merged

Add next_version parameter to release notes update actions#706
iangmaia merged 4 commits intotrunkfrom
iangmaia/fix-release-notes-version-bump

Conversation

@iangmaia
Copy link
Copy Markdown
Contributor

@iangmaia iangmaia commented Mar 30, 2026

Summary

Fixes: AINFRA-2242

  • Adds an optional next_version parameter to android_update_release_notes and ios_update_release_notes actions, so callers can provide the correct next version directly
  • Deprecates the new_version parameter, which uses a built-in calculator that assumes minor version caps at 9 (WordPress/Jetpack convention) — causing incorrect bumps for apps using semantic versioning (e.g. Pocket Casts: 8.9 → 9.0 instead of 8.10)
  • Adds validation requiring at least one of next_version or new_version (non-empty)

Test plan

  • bundle exec rspec spec/android_update_release_notes_spec.rb spec/ios_update_release_notes_spec.rb — all pass
  • bundle exec rubocop — no violations
  • Existing callers using new_version continue to work (backward compatible)
  • New callers using next_version get the value used directly as-is

🤖 Generated with Claude Code

The `android_update_release_notes` and `ios_update_release_notes` actions
used a built-in calculator that assumes minor version caps at 9 (WordPress/
Jetpack convention). This caused apps using semantic versioning (e.g. Pocket
Casts) to get incorrect version bumps (8.9 → 9.0 instead of 8.10).

Add an optional `next_version` parameter so callers can provide the correct
next version directly. Deprecate the `new_version` parameter in favor of it.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@iangmaia iangmaia self-assigned this Mar 30, 2026
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds support for explicitly supplying the next release version when updating Android/iOS release notes, avoiding the current built-in “minor rolls over at 9” version bump logic that breaks strict semver flows.

Changes:

  • Add optional next_version parameter (preferred) to android_update_release_notes and ios_update_release_notes; deprecate new_version.
  • Add runtime validation requiring at least one of next_version or new_version.
  • Extend Android/iOS action specs to cover next_version behavior, precedence, and missing-parameter error.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
lib/fastlane/plugin/wpmreleasetoolkit/actions/ios/ios_update_release_notes.rb Accept next_version, deprecate new_version, add “must provide one” validation.
lib/fastlane/plugin/wpmreleasetoolkit/actions/android/android_update_release_notes.rb Same as iOS action for Android implementation.
spec/ios_update_release_notes_spec.rb Add tests for next_version direct usage, precedence, and missing params error.
spec/android_update_release_notes_spec.rb Mirror iOS tests for Android action.
CHANGELOG.md Document the added next_version option and semver bump fix in Trunk.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Comment on lines +42 to +43
deprecated: 'Use `next_version` instead. This parameter computes the next version using a built-in calculator ' \
'that assumes the minor version rolls over to the next major at 9, which is incorrect for apps using semantic versioning',
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that the "This parameter computes the next version…" sentence was just after the "Use next_version instead" sentence made me think at first that the "This parameter" was referencing "next_version", not "new_version".

I wonder if we couldn't adjust the wording of this to make it less ambiguous 🤔 We could put the "Use next_version instead" sentence at the very end, which would avoid the confusion… but would make the important bit less visible than the FYI bit, so maybe not the best…

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated tweaking the wording on 169bb36

Comment on lines +42 to +50
deprecated: 'Use `next_version` instead. This parameter computes the next version using a built-in calculator ' \
'that assumes the minor version rolls over to the next major at 9, which is incorrect for apps using semantic versioning',
optional: true,
type: String),
FastlaneCore::ConfigItem.new(key: :next_version,
description: 'The next version to use as the section title in the release notes. ' \
'When provided, this value is used directly instead of computing it from `new_version`. ' \
'Use this if your app does not follow the default versioning convention (minor capped at 9)',
optional: true,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same remarks (wording of the deprecated attribute + use of conflicting_options in both conflicting ConfigItems)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍
Updated on 169bb36

@iangmaia iangmaia merged commit 4d560e1 into trunk Mar 30, 2026
6 checks passed
@iangmaia iangmaia deleted the iangmaia/fix-release-notes-version-bump branch March 30, 2026 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants