v2: Establish branching strategy for v2 development

[felixweinberger]

Summary

Define and document the branching strategy for v2 development to ensure clean separation between stable v1 releases and breaking v2 changes.

Motivation and Context

With v2 development underway, we need a clear branching strategy to:

• Keep main stable for v1.x releases and patches
• Allow v2 breaking changes to be developed in parallel
• Enable alpha/beta releases of v2 without disrupting v1 users

Proposed Approach

Branch Structure

• main - stable v1.x releases, bug fixes, non-breaking features
• v2 - v2 development branch with breaking changes

Workflow

1. v1 bug fixes and non-breaking changes go to main
2. v2 features and breaking changes go to v2 branch
3. Periodically merge main into v2 to pick up bug fixes
4. When v2 is ready for GA, merge v2 into main

Release Tagging

• v1.x.x releases from main
• v2.0.0-alpha.x / v2.0.0-beta.x releases from v2 branch

Open Questions

• Should we use next instead of v2 as the branch name?
• npm dist-tags: publish v2 prereleases under next tag?
• When to create the v2 branch? (now vs after initial planning)

Additional context

This should be set up early in v2 development to avoid confusion and merge conflicts.