Skip to content

Templates Lifecycle

This document describes the full lifecycle of a template from idea to deprecation, including states, promotion criteria, and responsibilities. It is written for architects, engineers, and template maintainers.

Templates progress through defined lifecycle states from initial experimentation to stable production use and eventual deprecation. Understanding these states helps maintainers and users make informed decisions about template usage.

Important

Templates must progress through lifecycle states systematically. Skipping states or promoting prematurely can lead to quality issues and customer dissatisfaction.

Lifecycle States

State Description Usage Support Level
Draft Initial experimentation Internal testing only No support
Experimental Used in test/internal projects only Internal projects, proof-of-concepts Limited support
Beta Used in limited real projects Early adopter customers, pilot projects Standard support
Stable Default choice for relevant scenarios All customers, production use Full support
Deprecated Scheduled for removal/replacement Existing projects only, no new projects Migration support only

Draft

Characteristics: - Initial experimentation and proof-of-concept - Not ready for any production use - May have incomplete features or known issues - No documentation or support

Usage: - Internal testing only - Template author and close collaborators - Not available to customers

Experimental

Characteristics: - Basic functionality working - Used in internal or test projects - May have limitations or known issues - Basic documentation available

Usage: - Internal projects - Proof-of-concepts - Test environments - Not recommended for customer production

Beta

Characteristics: - Core functionality complete and tested - Used in limited real projects - May have minor issues or limitations - Documentation available

Usage: - Early adopter customers - Pilot projects - Limited production use - Requires customer agreement

Stable

Characteristics: - Fully tested and production-ready - Used widely in production - Well-documented - Full support available

Usage: - All customers - Production use recommended - Default choice for relevant scenarios - Full support and maintenance

Deprecated

Characteristics: - Scheduled for removal or replacement - No new projects should use - Migration path available - Limited support

Usage: - Existing projects only - No new projects - Migration recommended - Support for migration only

Promotion Criteria

Draft → Experimental

Criteria: - [ ] Basic functionality implemented - [ ] Can generate valid project structure - [ ] Basic tests passing - [ ] Used successfully in at least one internal project - [ ] Basic documentation written

Process: - Template author requests promotion - Architecture review - Approval from template maintainer

Experimental → Beta

Criteria: - [ ] Core functionality complete - [ ] Used successfully in 2+ internal projects - [ ] Tests passing (unit, integration) - [ ] Documentation complete - [ ] Known limitations documented - [ ] Customer agreement for beta use

Process: - Template author requests promotion - Architecture review - Customer agreement obtained - Approval from product/architecture lead

Beta → Stable

Criteria: - [ ] Used successfully in 3+ customer projects - [ ] No critical issues in production - [ ] Performance validated - [ ] Security review passed - [ ] Documentation complete and accurate - [ ] Support processes established

Process: - Template author requests promotion - Review of customer feedback - Architecture and security review - Approval from product/architecture lead

Stable → Deprecated

Criteria: - [ ] Replacement template available (if applicable) - [ ] Migration path defined - [ ] Deprecation notice published (6+ months advance) - [ ] Support plan for existing projects

Process: - Product/architecture lead initiates deprecation - ADR documenting deprecation decision - Communication to customers - Migration support plan

Deprecation Policy

Deprecation Timeline

  • Notice Period - Minimum 6 months advance notice
  • Support Period - Support for existing projects during notice period
  • Migration Support - Migration support and guidance
  • Removal - Template removed after migration period

Communication

  • Deprecation Notice - Published in documentation and release notes
  • Customer Notification - Direct notification to affected customers
  • Migration Guide - Migration guide provided
  • Support - Support for migration questions

Migration Support

  • Migration Guide - Step-by-step migration guide
  • Support - Support for migration questions
  • Timeline - Reasonable timeline for migration
  • Assistance - Assistance with migration if needed

Responsibilities and Ownership

Template Owner

Responsibilities: - Template design and implementation - Testing and validation - Documentation - Maintenance and updates - Promotion requests

Template Maintainer

Responsibilities: - Review promotion requests - Approve lifecycle state changes - Coordinate with architecture team - Ensure quality standards

Architecture Team

Responsibilities: - Architecture review - Pattern consistency - Quality standards - Deprecation decisions

Product Team

Responsibilities: - Customer communication - Beta customer selection - Deprecation communication - Migration support coordination

Examples

Example 1: Microservice Template

  • Draft - Initial experimentation with Clean Architecture
  • Experimental - Used in internal projects
  • Beta - Used in 2 customer pilot projects
  • Stable - Used in 10+ customer projects, default for microservices
  • Current State - Stable

Example 2: API Gateway Template

  • Draft - Initial design
  • Experimental - Used in test projects
  • Beta - Used in 1 customer project
  • Current State - Beta (promoting to Stable after 2 more projects)