✨ Add label-based version increment to automated beta branch creation

[Copilot]

This PR enhances the Copilot instructions with automated beta branch creation functionality that uses GitHub labels to determine the appropriate version increment type, ensuring all future pull requests follow the project's development workflow with intelligent version management.

Key Changes

Label-Based Version Management

The system now uses GitHub issue/PR labels to determine version increment types:

• patch label - Bug fixes, documentation updates, minor improvements (4.3.1 → 4.3.2)
• minor label - New features, device support additions, non-breaking enhancements (4.3.1 → 4.4.0)
• major label - Breaking changes, API modifications, major architectural updates (4.3.1 → 5.0.0)

Enhanced Branch Targeting Strategy

The updated instructions include a comprehensive 4-step process:

1. Primary Target: Look for existing beta branches (e.g., beta-4.3.2, beta-4.4.0)
2. Automated Creation: If no beta branches exist, automatically create one based on detected labels
3. Fallback Target: Only use the latest branch if beta branch creation fails
4. Complete Toolchain: Provide all necessary detection and creation commands

Intelligent Label Processing

Added robust label detection and priority handling:

• Label priority: When multiple increment labels exist, uses highest priority (major > minor > patch)
• Fallback behavior: Defaults to patch increment when no relevant labels are found
• GitHub API integration: Uses github-mcp-server-get_issue and github-mcp-server-get_pull_request for label detection

Automated Beta Branch Creation Workflow

Complete git workflow with label-based version calculation:

# Detect version increment type from issue/PR labels
# Use GitHub API to check labels array for: patch, minor, major

# Calculate next version based on detected labels
if [[ labels contains "major" ]]; then
  NEXT_VERSION=$(node -p "const v=require('./package.json').version.split('.'); v[0]=parseInt(v[0])+1; v[1]='0'; v[2]='0'; v.join('.')")
elif [[ labels contains "minor" ]]; then
  NEXT_VERSION=$(node -p "const v=require('./package.json').version.split('.'); v[1]=parseInt(v[1])+1; v[2]='0'; v.join('.')")
else
  # Default to patch increment (includes when "patch" label found or no labels)
  NEXT_VERSION=$(node -p "const v=require('./package.json').version.split('.'); v[2]=parseInt(v[2])+1; v.join('.')")
fi

BETA_BRANCH="beta-${NEXT_VERSION}"
git fetch origin
git checkout -b "${BETA_BRANCH}" origin/latest
git push origin "${BETA_BRANCH}"

Benefits

• Explicit version control: Project maintainers can specify version increment type through labels before assigning issues
• Conservative defaults: Falls back to patch increment when no labels are present, ensuring safe version management
• Priority handling: Automatically resolves conflicts when multiple increment labels exist
• Automated workflow: Eliminates manual beta branch creation while maintaining proper release management practices
• Clear guidance: Provides project maintainers with explicit instructions on label usage

This ensures the development workflow always uses beta branches for testing changes before they reach the main development line, with intelligent version management based on the scope and impact of changes as indicated by GitHub labels.

Fixes #1274.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[donavanbecker]

@copilot, actually if there is no beta branch, can you create one based on the next possible version and then target it to that?

[Copilot]

@copilot, actually if there is no beta branch, can you create one based on the next possible version and then target it to that?

I've updated the branch targeting strategy to include beta branch creation functionality as requested. The Copilot instructions now include:

1. Automatic beta branch creation when no beta branches exist
2. Version calculation logic supporting patch (4.3.1→4.3.2), minor (4.3.1→4.4.0), and major (4.3.1→5.0.0) increments
3. Complete git workflow for creating and pushing new beta branches from the latest branch
4. Guidance on increment types - patch for bug fixes, minor for new features, major for breaking changes

The system will now automatically create a beta branch with the next appropriate version when none exists, then target that branch for PRs. This ensures the development workflow always uses beta branches for testing before merging to main.

Commit: 855d32e

[donavanbecker]

@copilot should we use labels to determine if it is a patch for bug fixes, minor for new features, major for breaking changes? so the labels could be patch, minor,major and would have to be set before assigning the issue to copilot

[Copilot]

@copilot should we use labels to determine if it is a patch for bug fixes, minor for new features, major for breaking changes? so the labels could be patch, minor,major and would have to be set before...

I've updated the Copilot instructions to use labels for determining version increment types as suggested. The system now:

1. Checks for labels on issues/PRs before creating beta branches: patch, minor, major
2. Uses label priority when multiple increment labels exist (major > minor > patch)
3. Falls back to patch increment when no relevant labels are found
4. Provides clear guidance for project maintainers on which labels to set before assigning issues to Copilot

The label-based logic is integrated into the beta branch creation workflow, making version management more explicit and intentional rather than always defaulting to patch increments.

Commit: 106beb6