Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/.release-please-manifest.json
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
{
".": "0.1.2"
".": "0.1.0"
Copy link

Copilot AI Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release-please manifest version is being downgraded to 0.1.0, but the repo currently advertises 0.1.2 in other release-tracked files (e.g., pyproject.toml and src/ai_company/init.py). This mismatch will likely cause Release Please to generate duplicate/incorrect next versions (e.g., v0.1.1) and can break the release/tagging pipeline. Align the manifest with the actual current released version (or, if intentionally resetting history, update all release-tracked files/tags consistently).

Suggested change
".": "0.1.0"
".": "0.1.2"

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Version downgrade will conflict with existing git tags

This change sets the Release Please manifest back to 0.1.0, but versions 0.1.1 and 0.1.2 have already been fully released — both pyproject.toml and src/ai_company/__init__.py are currently pinned to "0.1.2", and git tags v0.1.1 and v0.1.2 exist in the repository.

Release Please uses this manifest as its source of truth for "the last released version." After merging this PR:

  1. Release Please will calculate the next version by bumping from 0.1.0 (e.g. it will try to produce 0.1.1 again).
  2. It will also attempt to rewrite pyproject.toml and src/ai_company/__init__.py (both listed as extra-files in release-please-config.json) from 0.1.2 back toward a 0.1.1-era value.
  3. When it tries to push a tag, the v0.1.1 (and potentially v0.1.2) tag already exists — the release workflow will either fail or, worse, create a broken/duplicate release.

If the intent is to cut a fresh release cycle starting from a clean base, the manifest should be set to 0.1.2 (the actual last released version), not 0.1.0. Downgrading the manifest value is not a supported Release Please operation and will corrupt the automated release pipeline.

Suggested change
".": "0.1.0"
".": "0.1.2"
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/.release-please-manifest.json
Line: 2

Comment:
**Version downgrade will conflict with existing git tags**

This change sets the Release Please manifest back to `0.1.0`, but versions `0.1.1` and `0.1.2` have already been fully released — both `pyproject.toml` and `src/ai_company/__init__.py` are currently pinned to `"0.1.2"`, and git tags `v0.1.1` and `v0.1.2` exist in the repository.

Release Please uses this manifest as its source of truth for "the last released version." After merging this PR:

1. Release Please will calculate the next version by bumping from `0.1.0` (e.g. it will try to produce `0.1.1` again).
2. It will also attempt to rewrite `pyproject.toml` and `src/ai_company/__init__.py` (both listed as `extra-files` in `release-please-config.json`) from `0.1.2` back toward a `0.1.1`-era value.
3. When it tries to push a tag, the `v0.1.1` (and potentially `v0.1.2`) tag already exists — the release workflow will either fail or, worse, create a broken/duplicate release.

If the intent is to cut a fresh release cycle starting from a clean base, the manifest should be set to `0.1.2` (the actual last released version), not `0.1.0`. Downgrading the manifest value is not a supported Release Please operation and will corrupt the automated release pipeline.

```suggestion
  ".": "0.1.2"
```

How can I resolve this? If you propose a fix, please make it concise.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

Downgrading the version from 0.1.2 to 0.1.0 is incorrect and will disrupt the automated release workflow. The CHANGELOG.md confirms that versions 0.1.1 and 0.1.2 have already been released. This manifest file should always reflect the latest version to allow release-please to correctly calculate the next version. Please revert this to 0.1.2 to ensure the release process functions as expected.

Suggested change
".": "0.1.0"
".": "0.1.2"

}
2 changes: 1 addition & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Changelog

## [0.1.2](https://github.com/Aureliolo/ai-company/compare/v0.1.1...v0.1.2) (2026-03-11)
## [0.1.0](https://github.com/Aureliolo/ai-company/compare/v0.0.0...v0.1.0) (2026-03-11)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comparison URL references a likely non-existent tag

The new header links to compare/v0.0.0...v0.1.0. A v0.0.0 tag does not appear to have ever been created in this repository — the project's first tracked release was v0.1.0. GitHub will render this comparison link as a 404, making the CHANGELOG entry non-functional for anyone trying to trace what changed.

If the intent is to mark this as the "initial" release, the conventional approach is to use the first commit SHA or the repository creation point, not an invented v0.0.0 tag.

Suggested change
## [0.1.0](https://github.com/Aureliolo/ai-company/compare/v0.0.0...v0.1.0) (2026-03-11)
## [0.1.0](https://github.com/Aureliolo/ai-company/releases/tag/v0.1.0) (2026-03-11)
Prompt To Fix With AI
This is a comment left during a code review.
Path: CHANGELOG.md
Line: 3

Comment:
**Comparison URL references a likely non-existent tag**

The new header links to `compare/v0.0.0...v0.1.0`. A `v0.0.0` tag does not appear to have ever been created in this repository — the project's first tracked release was `v0.1.0`. GitHub will render this comparison link as a 404, making the CHANGELOG entry non-functional for anyone trying to trace what changed.

If the intent is to mark this as the "initial" release, the conventional approach is to use the first commit SHA or the repository creation point, not an invented `v0.0.0` tag.

```suggestion
## [0.1.0](https://github.com/Aureliolo/ai-company/releases/tag/v0.1.0) (2026-03-11)
```

How can I resolve this? If you propose a fix, please make it concise.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Release history for v0.1.1 and v0.1.2 is silently erased

The previous CHANGELOG.md had a header for [0.1.2] comparing v0.1.1...v0.1.2. After this change, any features or fixes that were specifically shipped in v0.1.1 and v0.1.2 are now all attributed to a single v0.1.0 entry. The feature list in the body of this section still contains commits from all three releases, which means the comparison URL (v0.0.0...v0.1.0) will not actually cover all the listed commits — those commits only exist up to v0.1.2.

Users, contributors, or automated tooling (e.g., dependency bots) that look at the CHANGELOG to understand what changed between versions will get inaccurate information. The two intermediate release sections should be preserved, not collapsed.

Prompt To Fix With AI
This is a comment left during a code review.
Path: CHANGELOG.md
Line: 3

Comment:
**Release history for v0.1.1 and v0.1.2 is silently erased**

The previous `CHANGELOG.md` had a header for `[0.1.2]` comparing `v0.1.1...v0.1.2`. After this change, any features or fixes that were specifically shipped in `v0.1.1` and `v0.1.2` are now all attributed to a single `v0.1.0` entry. The feature list in the body of this section still contains commits from all three releases, which means the comparison URL (`v0.0.0...v0.1.0`) will not actually cover all the listed commits — those commits only exist up to `v0.1.2`.

Users, contributors, or automated tooling (e.g., dependency bots) that look at the CHANGELOG to understand what changed between versions will get inaccurate information. The two intermediate release sections should be preserved, not collapsed.

How can I resolve this? If you propose a fix, please make it concise.



### Features
Expand Down
2 changes: 1 addition & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -196,7 +196,7 @@ venv = ".venv"
# ---------------------------------------------------------------------------
[tool.commitizen]
name = "cz_conventional_commits"
version = "0.1.2" # x-release-please-version
version = "0.1.0" # x-release-please-version
tag_format = "v$version"

# ---------------------------------------------------------------------------
Expand Down
2 changes: 1 addition & 1 deletion src/ai_company/__init__.py
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
"""AI Company - Framework for orchestrating autonomous AI agents."""

__version__ = "0.1.2" # x-release-please-version
__version__ = "0.1.0" # x-release-please-version