feat: include past 3 versions in Google Play release notes

[graycreate]

Summary

• Add feedback header at the top of release notes: 唯一问题反馈渠道:https://v2er.app/help
• Include current version + up to 2 previous versions in release notes
• Version sections separated with --- vX.Y.Z --- headers
• Respects Google Play's 500 character limit per language

Example Output

唯一问题反馈渠道:https://v2er.app/help

V2er v1.0.5

• Add long-press reply feature
• Fix login issue

--- v1.0.4 ---
• Improve performance
...

Changes

• Rewrote "Create whatsnew directory" step in release.yml
• Added multi-version commit collection
• Added character limit enforcement (500 chars for Google Play)

Test plan

• Trigger a release and verify whatsnew content in workflow logs
• Check Google Play Console for correct release notes

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR enhances the Google Play release notes generation in the GitHub Actions workflow to include the current version plus up to 2 previous versions, with a feedback header and 500-character limit enforcement per Google Play's requirements.

Key Changes:

• Adds feedback header URLs for both English and Chinese release notes
• Implements multi-version commit collection using git tag ranges
• Enforces Google Play's 500-character limit per language
• Refactors release notes generation from emoji-based sections with contributors to compact bullet-point format

[Copilot]

The character counting logic is incorrect. wc -c counts bytes, not characters. For multi-byte UTF-8 characters (like Chinese characters in the feedback header "唯一问题反馈渠道"), this will count multiple bytes per character. However, ${#notes} counts characters correctly. This mismatch means the character limit enforcement may be inaccurate - the initial length calculation uses byte count while the subsequent additions use character count.

[Copilot]

The character counting logic is incorrect. wc -c counts bytes, not characters. For multi-byte UTF-8 characters (like Chinese characters in the feedback header "唯一问题反馈渠道"), this will count multiple bytes per character. However, ${#notes} counts characters correctly. This mismatch means the character limit enforcement may be inaccurate - the initial length calculation uses byte count while the subsequent additions use character count.

[Copilot]

The associative arrays are redeclared inside the loop without being cleared between iterations. In bash, when you declare -A an existing associative array, it doesn't clear its contents. This means commits from previous iterations will accumulate in the arrays, leading to duplicate entries in the release notes for version i=1.

[Copilot]

The associative arrays are redeclared inside the loop without being cleared between iterations. In bash, when you declare -A an existing associative array, it doesn't clear its contents. This means commits from previous iterations will accumulate in the arrays, leading to duplicate entries in the release notes for version i=1.

[Copilot]

The character limit check adds 2 to account for newlines, but this is inconsistent. When writing to the file with echo "$notes", bash adds a single newline character (1 byte), not 2. This will cause the actual file size to be smaller than the calculated CURRENT_LEN, leading to inaccurate character limit enforcement.

[Copilot]

The character limit check adds 2 to account for newlines, but this is inconsistent. When writing to the file with echo "$notes", bash adds a single newline character (1 byte), not 2. This will cause the actual file size to be smaller than the calculated CURRENT_LEN, leading to inaccurate character limit enforcement.

[Copilot]

Variable naming is inconsistent. In generate_version_notes, the parameter references use bugs (line 692) but in the function body it's referenced as ${#bugs[@]} (line 702). The array is passed as bug_ref in collect_version_commits (line 662) and assigned from curr_bugs, prev_bugs, etc. The naming should be consistent - either use bugs everywhere or bug everywhere to match the pattern of feat/improve/perf.

[Copilot]

The output variable in generate_version_notes accumulates strings with newlines embedded using $'\n'. However, when echoed at the end, this will produce the correct multi-line output. But there's a subtle issue: if all arrays are empty, the function will echo an empty string which is fine, but the logic doesn't explicitly handle this case, making the function's behavior less clear.

Suggested change

	echo "$output"
	if [ -z "$output" ]; then
	# Explicitly handle the case where there are no version notes
	echo ""
	else
	echo "$output"
	fi

[Copilot]

The loop logic for handling the last tag (when i+1 >= number of tags) uses ${TAGS[$i]}~5..${TAGS[$i]} which gets commits leading up to the tag, not commits between tags. This will show the wrong commits for the oldest version in the release notes. The range should be from the previous tag (or an appropriate earlier reference) to ${TAGS[$i]}.

Suggested change

	# Last tag - get commits before it
	declare -A prev_features prev_bugs prev_improvements prev_performance
	collect_version_commits "${TAGS[$i]}~5..${TAGS[$i]}" prev_features prev_bugs prev_improvements prev_performance
	# Last tag - get commits from repository root to this tag
	declare -A prev_features prev_bugs prev_improvements prev_performance
	collect_version_commits "$(git rev-list --max-parents=0 ${TAGS[$i]})..${TAGS[$i]}" prev_features prev_bugs prev_improvements prev_performance

[Copilot]

The loop iterates over indices 0 and 1 to collect previous versions, but the condition checks if i < ${#TAGS[@]} which may cause issues. When TAGS has only 1 element (index 0), the loop will try to access TAGS[1] in the first condition branch, which doesn't exist. The loop should handle the case where there are fewer than 3 tags more carefully.