fix: update semantic-release branches to main and v1

[dev-davexoyinbo]

No description provided.

[qodo-code-review]

Review Summary by Qodo

Update semantic-release branches configuration to main and v1

🐞 Bug fix

Walkthroughs

Description

• Update semantic-release branches configuration from "release" to "main" and "v1"
• Configure v1 branch with dedicated release channel for versioning

Diagram

flowchart LR
  old["branches: release"]
  new["branches: v1 channel + main"]
  old -- "update configuration" --> new

Loading

File Changes

1. release.config.js ⚙️ Configuration changes +1/-1

Update release branches configuration

• Changed branches array from single "release" branch to multiple branches
• Added v1 branch with dedicated "v1" release channel
• Added "main" branch for primary releases

release.config.js

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0)

1. Branch config/workflow mismatch 🐞 Bug ≡ Correctness

Description

.github/workflows/versioned.yml runs npx semantic-release on every v* branch push, but
release.config.js only allows releases from v1 and main, so release jobs on branches like v2
will no-op (no publish/tag) even though CI executes the release step.

Code

release.config.js[2]

Evidence

versioned.yml is set up to run semantic-release for any v* branch, but semantic-release will
only perform a release when the current branch is listed in release.config.js (currently only v1
and main).

release.config.js[1-3]
.github/workflows/versioned.yml[3-8]
.github/workflows/versioned.yml[37-59]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The CI `Versioned` workflow triggers on `v*` branches and executes `semantic-release`, but `semantic-release` is configured to only release from `v1` and `main`. This causes release runs on other `v*` branches to succeed without publishing anything.

## Issue Context
- `versioned.yml` triggers for all `v*` branches and runs `npx semantic-release`.
- `release.config.js` restricts semantic-release branches to `v1` and `main`.

## Fix Focus Areas
- release.config.js[1-3]
- .github/workflows/versioned.yml[3-8]
- .github/workflows/versioned.yml[37-59]

## Proposed fix
Decide the intended release sources:
- If you want releases from multiple `vN` branches: update `release.config.js` to include those branches (e.g., add `v2` / additional maintenance branch definitions).
- If you only want releases from `v1` and `main`: narrow `.github/workflows/versioned.yml` triggers/conditions so it only runs the release job for `v1` (and/or remove the release job from `versioned.yml` for other `v*` branches).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. v1 major not constrained 🐞 Bug ☼ Reliability

Description

The v1 release branch is configured without a maintenance range, so a breaking-change commit on
v1 can produce a 2.0.0+ release from the v1 line even though the repo already has a v2 major line.

Code

release.config.js[2]

Evidence

The repo is already on major 2, but the new semantic-release config treats v1 as a release branch
without bounding it to the 1.x line, making it possible for v1 to generate 2.x releases if breaking
changes land there.

release.config.js[1-3]
package.json[1-5]
CHANGELOG.md[47-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `v1` branch entry in `release.config.js` has no version range constraint. In a multi-major setup (repo already at v2), maintenance branches should typically be range-bounded so they cannot release outside their intended major.

## Issue Context
- `release.config.js` defines `v1` with a `channel` but no `range`.
- The repo shows a v2 line (package.json is 2.0.0 and CHANGELOG has a `v2.0.0` section).

## Fix Focus Areas
- release.config.js[1-3]
- package.json[1-6]
- CHANGELOG.md[47-66]

## Proposed fix
Update the `v1` branch definition to include an explicit maintenance range for the 1.x line (per your release strategy), e.g. add a `range` that keeps `v1` releases within major 1. This prevents accidental 2.x releases from the v1 maintenance branch.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Release docs now incorrect 🐞 Bug ⚙ Maintainability

Description

AGENTS.md still documents releases happening on a release branch and a
.github/workflows/release.yml, which conflicts with the new main/v1 semantic-release branch
configuration and the current workflows.

Code

release.config.js[2]

Evidence

AGENTS.md explicitly claims releases happen on a release branch, but the repo’s active workflows
run semantic-release on main and v* branches and the config has been changed to v1/main.

AGENTS.md[44-48]
.github/workflows/main.yml[3-8]
.github/workflows/main.yml[37-59]
.github/workflows/versioned.yml[3-8]
release.config.js[1-3]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Documentation in `AGENTS.md` still instructs developers that releases happen on the `release` branch and references `.github/workflows/release.yml`. The PR changes the semantic-release branches to `main` and `v1`, and the repo’s workflows run releases from `main.yml` / `versioned.yml`.

## Issue Context
This will mislead contributors about how releases are triggered and where semantic-release runs.

## Fix Focus Areas
- AGENTS.md[44-48]
- .github/workflows/main.yml[3-8]
- .github/workflows/main.yml[37-59]
- .github/workflows/versioned.yml[3-8]

## Proposed fix
Update the referenced branch/workflow names and the description of when semantic-release runs to match the current CI + `release.config.js` branch strategy.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Branch config/workflow mismatch 🐞 Bug ≡ Correctness

.github/workflows/versioned.yml runs npx semantic-release on every v* branch push, but
release.config.js only allows releases from v1 and main, so release jobs on branches like v2
will no-op (no publish/tag) even though CI executes the release step.

Agent Prompt

## Issue description
The CI `Versioned` workflow triggers on `v*` branches and executes `semantic-release`, but `semantic-release` is configured to only release from `v1` and `main`. This causes release runs on other `v*` branches to succeed without publishing anything.

## Issue Context
- `versioned.yml` triggers for all `v*` branches and runs `npx semantic-release`.
- `release.config.js` restricts semantic-release branches to `v1` and `main`.

## Fix Focus Areas
- release.config.js[1-3]
- .github/workflows/versioned.yml[3-8]
- .github/workflows/versioned.yml[37-59]

## Proposed fix
Decide the intended release sources:
- If you want releases from multiple `vN` branches: update `release.config.js` to include those branches (e.g., add `v2` / additional maintenance branch definitions).
- If you only want releases from `v1` and `main`: narrow `.github/workflows/versioned.yml` triggers/conditions so it only runs the release job for `v1` (and/or remove the release job from `versioned.yml` for other `v*` branches).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[github-actions]

🎉 This PR is included in version 1.6.0 🎉

The release is available on:

• npm package (@main dist-tag)
• GitHub release

Your semantic-release bot 📦🚀