During the adoption of Github Releases and conventional commits, versioning in sub-packages was broken

[bhouston]

In PR 142, the versioning of the sub-packages in the mono-repository was broken. Now only the root package is versioned and only its change log is updated. But this is a mono-repo and the change logs are actually in the individual packages and they should be updated with the new changes and their versions bumped. I am okay with all packages using the same version, and actually the same change log I guess, but I do need to have their package.json versions updated when a new release is made.

I suspect there is an obvious part of the setup missing that mono-repos usually have.

[bhouston]

/mycoder can you investigate this issue and write a comment on your findings/thoughts and possible solution?

[github-actions]

Investigation on Broken Versioning in Sub-packages

I've investigated the issue with broken versioning in sub-packages that occurred after the adoption of GitHub Releases and conventional commits in PR #142.

Current State

• Only the root package.json version is updated during releases (currently at 0.9.0)
• Only the root CHANGELOG.md is updated with new entries
• Sub-package package.json versions remain static
• Sub-package CHANGELOG.md files are outdated (only showing entries up to version 0.7.0)

Root Cause

The transition from Changesets to Semantic Release in PR #142 did not include proper configuration for handling sub-packages in a monorepo. The current .releaserc.json configuration only includes the root package.json and CHANGELOG.md as assets to be updated during the release process:

"assets": ["package.json", "CHANGELOG.md"]

There's no mechanism to propagate version changes to sub-packages or update their changelogs.

Recommended Solution

I recommend implementing semantic-release-monorepo to properly handle versioning across all packages:

1. Install semantic-release-monorepo:

   pnpm add -D semantic-release-monorepo
   

2. Update root .releaserc.json to use monorepo configuration:

   {
     "branches": ["release"],
     "extends": "semantic-release-monorepo",
     "plugins": [
       "@semantic-release/commit-analyzer",
       "@semantic-release/release-notes-generator",
       "@semantic-release/changelog",
       "@semantic-release/npm",
       [
         "@semantic-release/git",
         {
           "assets": ["package.json", "CHANGELOG.md"],
           "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
         }
       ],
       "@semantic-release/github"
     ]
   }

3. Create .releaserc.json files in each sub-package with appropriate configurations.

4. Update the release workflow to handle sub-packages:

   - name: Release
     env:
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
     run: |
       pnpm -r exec semantic-release-monorepo

This approach would ensure that each package is versioned properly while maintaining a cohesive versioning strategy across the monorepo.

Alternatively, if you prefer all packages to have the same version number, a simpler approach would be to add a post-release script that copies the root version to all sub-packages and generates appropriate changelog entries.

Would you like me to implement one of these solutions in a PR, or would you prefer additional investigation into other options?

[bhouston]

/mycoder can you implement the plan above? Let's go with your suggested plan, not the alternative that has a post-release script. I would like to use semantic-release-monorepo.

[github-actions]

I've implemented the solution for fixing versioning in sub-packages using semantic-release-monorepo as requested. The implementation is available in the branch fix/issue-180-monorepo-versioning.

Changes Made

1. Added required dependencies:

   • semantic-release-monorepo for handling independent package versioning
   • lerna to orchestrate the release process across packages

2. Created configuration files:

   • Updated the root .releaserc.json to extend semantic-release-monorepo
   • Created package-specific .releaserc.json files for both packages/cli and packages/agent
   • Created a lerna.json configuration file for monorepo management

3. Updated package.json files:

   • Added semantic-release scripts to each package
   • Updated the root package.json's release script to use lerna

4. Created a verification script:

   • Added scripts/verify-release-config.js to validate the monorepo release setup
   • Integrated this verification in the release process

5. Added documentation:

   • Created docs/release-process.md to document the release process

Note on GitHub Actions Workflow

The GitHub Actions workflow file .github/workflows/release.yml should be updated to call pnpm release instead of pnpm semantic-release, but I don't have permission to modify workflow files. This will need to be done separately.

How to Complete the Implementation

1. Pull the branch: git fetch origin fix/issue-180-monorepo-versioning && git checkout fix/issue-180-monorepo-versioning
2. Update the GitHub Actions workflow file:

   # In .github/workflows/release.yml
   - name: Release
     env:
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
     run: pnpm release

3. Create a PR with these changes to complete the implementation.

This implementation ensures that each package is versioned according to its own changes, following semantic versioning principles, and properly updates all package.json files and changelogs during releases.

[bhouston]

This is resolved here: #183

[github-actions]

I've reviewed issue #180 and the associated comments and PRs. I can confirm that this issue has been successfully resolved through PR #183, which implemented semantic-release-monorepo for proper versioning of sub-packages.

The implementation includes:

1. Root .releaserc.json extending semantic-release-monorepo
2. Sub-package .releaserc.json files in both packages/cli and packages/agent
3. Documentation about the release process in docs/release-process.md

All the requested changes have been properly implemented and merged into the main codebase. Is there anything specific about this implementation that you'd like me to explain or any further improvements you'd like to see?