[FEATURE]: Automate release steps as requested in #7500

[ADITYATIWARI342005]

Implements automated release steps for Jaeger per #7500: auto-create release PR with changelog and UI upgrade, automate tag creation with user confirmation, and keep final release + artifacts workflow manual.

Changes Made

• prepare.sh script: scripts/release/prepare.sh
  • Two-mode operation: PR creation mode and tag creation mode
  • PR mode: Generates changelog, updates CHANGELOG.md, updates jaeger-ui submodule, creates branch, commits, pushes, opens PR
  • Tag mode: Creates and pushes signed tags with user confirmation (--create-tags flag)
  • Linear execution with no functions - follows maintainer feedback
  • Proper dry run support for both modes
• start.sh integration: Updated to provide exact commands with pre-populated versions
• Docs: RELEASE.md updated to include the automated option

Usage

Create Release PR

# Step 1: Create tracking issue
bash scripts/release/start.sh

# Step 2: Create release PR (run command from tracking issue)
bash ./scripts/release/prepare.sh v1.73.0 v2.10.0

Create Tags (After PR is merged)

# Step 3: Create and push tags with confirmation
bash ./scripts/release/prepare.sh v1.73.0 v2.10.0 --create-tags

Dry Run

# Preview changes without creating PR or tags
DRY_RUN=true bash ./scripts/release/prepare.sh v1.73.0 v2.10.0
DRY_RUN=true bash ./scripts/release/prepare.sh v1.73.0 v2.10.0 --create-tags

Features

• ✅ Two-mode operation: PR creation and tag creation modes
• ✅ Automated PR creation with changelog and UI submodule updates
• ✅ Automated tag creation with user confirmation for safety
• ✅ Pre-populated versions in tracking issue commands
• ✅ Dry run support for previewing changes in both modes
• ✅ Linear execution - no functions, follows maintainer feedback
• ✅ Safe defaults requiring explicit confirmation for tag operations
• ✅ Proper mode separation - file operations only in PR mode

Implementation Details

• No functions: Linear execution from top to bottom as requested
• No validation: Let git and make commands fail naturally
• Obvious operations: Simple shell commands, no awk complexity
• Fail hard: No fallbacks or complex error handling
• Proper dry run: Skips git operations, keeps file operations for inspection

Manual Steps (unchanged)

• Create GitHub release
• Trigger artifacts workflow
• Human review/approval

Testing

The script has been tested with:

• Syntax validation (bash -n)
• Argument parsing for both modes
• Dry run functionality
• Mode separation logic
• Line ending compatibility

Closes #7500

[ADITYATIWARI342005]

Hi @yurishkuro @joe-elliott
I have implemented this PR for #7500, but I had some follow-ups

1. Make Target Naming: Uses automate-release vs the suggested prepare-release in Upgrade gRPC to 1.38.x #3056. Should this be same as there.
2. As per my knowledge from discussions and issues, v1 will be discontinued from next year, So should I remove the release version feature from the script for v1.

[yurishkuro]

1. remove powershell, we do not use Windows for release
2. the release starts with bash scripts/release/start.sh which creates an issue with the checklist. That checklist needs to be slightly fixed to specify the right versions in the right places (which are already determined when running start.sh)
3. The checklist needs to include the new automation steps as exact commands to be run
4. Don't call scripts "automate-release", it's a meaningless name. Call by the action they are actually doing.
5. Remove the README. The release instructions are in the root RELEASES.md

[ADITYATIWARI342005]

Hi @yurishkuro
I have implemented the changes as you instructed and I have updated the PR description for the latest changes, Please review it.
I was unable to test PR creation, But I have verified the logic, It should pass, Please review that too.
Thank you.

[ADITYATIWARI342005]

Hi @yurishkuro
Thank you for giving your time to review the previous Changes in this PR, From your latest review I realised that the Implementation was overly complicated and had multiple logic issues due to its unjustified length.

However, based on these realisations, and all the reviews you gave till now, I have made optimal changes with refrence to the steps mentioned in the issue description #7500 .

Please review this optimal approached Implementation,

Thank you.