🧭 What Are Per-Entity Version Logs?

Each entity in JCB (e.g. a View, Field, Template, Layout, Dynamic GET, etc.) maintains its own version history — allowing you to document significant changes and track the evolution of your component logic over time.

Think of it as Git-like commit messages at the entity level.

These logs can be used to:

• Annotate why a change was made
• Reference when and by whom it was done
• Mark internal “releases” or milestones
• Support version-aware resets and forks

Unlike raw Git history, this is fully integrated inside the JCB GUI and compiler, and optionally included in generated README files or exported blueprints.

📌 Where Can You Find It?

You’ll see a "Version History" or "Changelog" field in most major JCB entities, including:

• Admin Views
• Custom Admin Views
• Site Views
• Templates
• Snippets
• Layouts
• Field Types
• Custom Code blocks
• Dynamic GETs
• Blueprints and Package metadata

The history is often stored in a markdown-like format with manual entries per line (e.g., date, change, author/notes).

🧪 Example Version Log

Version History for Custom Admin View: ImportQueue

• v1.0.0 – Initial creation of view and layout
• v1.1.0 – Added Dynamic GET for batch import list
• v1.2.0 – Refactored toolbar buttons (now using new snippet)
• v1.2.1 – Fixed routing ACL permissions
• v1.3.0 – Updated to support Joomla 5 namespace changes

🛠️ How to Use It

• Open the entity (view, template, etc.)
• Locate the Version or History field
• Use structured entries (e.g., version + description)
• Save your changes
• The log is stored in the blueprint and can be exported or displayed in the compiled documentation

This makes it easier to reset/fork with confidence.

🔁 Sync with Git or External Tools

While this versioning is internal to JCB, it can be exported to Git via blueprint push/pull, or used to generate component-level changelogs automatically (with the compiler’s changelog builder).

You can also configure your own changelog parser or generator using the stored metadata.

✅ Benefits

• ✔️ Per-entity traceability
• ✔️ Team collaboration and audit trail
• ✔️ Easier reset/fork workflows
• ✔️ Compile-time export to README or docs
• ✔️ Helpful in debugging regressions or cross-version issues

📘 Related Features

• 📦 Auto-generated changelog from commits
• 🔁 Blueprint sync via Git
• 📄 Per-entity README generation

💡 Pro Tip

Use semantic versioning and short notes like:

• v2.1.1 – 🐛 Bugfix for missing field in modal
• v2.2.0 – ✨ New dashboard layout added
• v3.0.0 – 🔥 Breaking change: switched Dynamic GET structure

📍 Conclusion

JCB’s version history logs help you manage change — not just globally, but at the atomic level of every feature. When working across teams or maintaining large component libraries, this transparency pays off in reliability, clarity, and maintainability.