What It Does

When you push a component blueprint or compiled package to a Git repository:

• JCB scans change log messages tied to the sql Updates versioning setup.
• It extracts Git commit messages between the last and current release.
• It compiles those into a markdown-formatted changelog.
• The changelog is stored alongside your component package and metadata.

You can then:

• View and edit the changelog inside JCB in the Component SQL Updates.
• Attach it to a release tag.
• Publish it in your extension’s update metadata.
• Display it in the Joomla admin interface using JCB’s version tracking UI.

How It Works

Version Tags

Every blueprint can be assigned a semantic version number (e.g., v1.2.0). When you push this version to Git:

• JCB finds the previous tag (e.g., v1.1.0)
• It extracts all commits between the two tags.

Commit Parsing

JCB supports conventional commit formatting (recommended), such as:

• feat: added export feature to admin views
• fix: resolved ACL visibility bug on custom forms
• chore: updated translations for languages

You can also write free-form commit messages — JCB will include them all chronologically.

Changelog Formatting

The output is rendered in Markdown and may include:

• Date and time
• Version number
• List of commits with author and message
• Optional links to Git repository or file changes

Example Output:

## [v1.2.0] — 2025-06-30

- feat: Added remote publishing to update server streams
- fix: Corrected layout inheritance for site views
- chore: Updated field injection point tooltips

Integration Options

• 🎯 Display changelog inside the Joomla admin after component update
• 📦 Bundle the changelog in your release ZIP as CHANGELOG.md
• 🔁 Export changelogs to an external repo or status dashboard
• 🌐 Sync changelog with OpenCollective, GitHub, or internal CI/CD systems

Benefits

• ✅ Developer-Friendly
  No more maintaining text-based logs manually. Developers just commit normally and JCB handles the rest.
• 🕵️‍♂️ Transparent
  Site owners, clients, and contributors can see what has changed at a glance — from backend UIs to libraries.
• 📄 Release-Ready
  Changelogs are tagged, formatted, and exportable — ready to be shared as release notes or attached to update servers.
• 📊 Audit Trail
  Maintain a clear, verifiable trail of every change to your components — ideal for enterprise and collaborative environments.

Best Practices

• Use conventional commits where possible.
• Keep commits scoped to features, fixes, or content changes.
• Use semantic versioning to tag releases in JCB (e.g., 1.3.0 → 1.4.0).
• Avoid force-pushing branches with history rewrites to preserve changelog accuracy.

Conclusion

The auto-generated changelog feature gives you a professional-grade release workflow with minimal overhead. It ties together versioning, packaging, and transparency — ensuring every build carries a clear and complete development history.

Summary

JCB automatically generates changelogs for your component releases by extracting commit messages and version history from your Git repository. This eliminates the need for manual tracking of changes and ensures every package is accompanied by a clean, informative release log.