Release Process

Version Numbering

Follow [[Semantic Versioning]

• MAJOR: Breaking changes
  • Example: 1.5.3 → 2.0.0 (API interface changes, incompatible with existing code)
• MINOR: New features (backward compatible)
  • Example: 1.5.3 → 1.6.0 (new functions added, existing features preserved)
• PATCH: Bug fixes (backward compatible)
  • Example: 1.5.3 → 1.5.4 (bug fixes in existing functionality)

Release Steps

1. Create release branch from develop

   git checkout develop
   git checkout -b release/v1.2.0

2. Update version numbers

   // package.json
   {
     "version": "1.2.0"
   }

3. Update CHANGELOG.md

   ## [1.2.0] - 2025-08-06
   ### Added
   - User profile editing functionality
   - Dark mode support
   
   ### Fixed
   - Memory leak issue during login

4. Test thoroughly

   npm test
   npm run e2e-test
   npm run integration-test

5. Merge to main and tag

   git checkout main
   git merge release/v1.2.0
   git tag -a v1.2.0 -m "Release version 1.2.0"
   git push origin main --tags

6. Merge back to develop

   git checkout develop
   git merge main
   git push origin develop
   git branch -d release/v1.2.0  # Clean up release branch

7. Create GitHub release

   • Navigate to GitHub repository's Releases tab
   • Click "Create a new release"
   • Select tag v1.2.0 and write release notes

Version Examples

• 1.0.0: First stable release
• 1.1.0: Added notification system
• 1.1.1: Fixed notification bug
• 1.2.0: Added user dashboard
• 2.0.0: Complete API restructure (breaking changes)

Pre-release Versions

• 1.2.0-alpha.1: Early alpha version
• 1.2.0-beta.1: Beta version for testing
• 1.2.0-rc.1: Release candidate

Best Practices

• Always update documentation with version changes
• Include migration guides for MAJOR versions
• Use consistent commit message format
• Automate version bumping when possible
• Keep CHANGELOG.md up to date with each release