Release Guidelines and Schedule

Version Numbering

RhoSocial ActiveRecord follows semantic versioning with specific guidelines for different release types: stable releases, development versions, and pre-release candidates.

Stable Release Version Format

MAJOR.MINOR.PATCH[.postN]

Where:

• MAJOR changes indicate substantial new features with breaking changes

• MINOR changes add functionality in a backward-compatible manner

• PATCH changes include only backward-compatible bug fixes

• .postN indicates post-release fixes for non-functional issues (optional)

Release Cycles

Major Releases (X.0.0)

• Include significant new features and potential breaking changes

• Minimum support period of 5 years

• Breaking changes are carefully considered and documented

• No fixed release schedule

• Requires thorough testing and documentation

Minor Releases (X.Y.0)

• Add new features in a backward-compatible way

• Minimum interval of 3 months between releases

• Include all previous patch fixes

• Backward compatibility maintained

• Feature additions and enhancements

Patch Releases (X.Y.Z)

• Focus solely on bug fixes

• Minimum interval of 1 month unless critical security fixes

• Released only when necessary

• No new features

• Strictly backward compatible

Post-Releases (X.Y.Z.postN)

• Address non-functional issues:

  • Documentation typos

  • Packaging errors

  • Metadata corrections

• Functionally identical to the base version

• Upgrade optional if base version works correctly

Development Versions

Format: X.Y.0.devN

• Based on major and minor version numbers

• Patch version is always 0

• .devN suffix indicates development status

• Not recommended for production use

• Version numbers may not be sequential

• Used for testing and development purposes

Pre-Release Versions

Alpha Releases

Format: X.Y.0.alphaN

• Early development stage

• Features may change

• API not stable

• Minimum 3 iterations

• One week minimum between stages

Beta Releases

Format: X.Y.0.betaN

• Feature freeze

• Only bug fixes and feature removals

• Minimum 3 iterations

• One week minimum between stages

Release Candidates

Format: X.Y.0.rcN

• Bug fixes only

• Potential stable release

• Minimum 3 iterations

• One week minimum between stages

Testing and Distribution

Testing Requirements

• All versions must pass complete unit test suite

• Test coverage maintained for all features

• Regression tests required for bug fixes

• Performance tests for optimization changes

• Integration tests for backend implementations

Distribution Notes

• Distribution packages (PyPI, etc.) exclude test files

• Users requiring test files should install from source:

  git clone https://github.com/rhosocial/python-activerecord.git
  cd python-activerecord
  pip install -e .[test]

• Test execution instructions available in source repository

Support Policy

Long-term Support

• Major versions supported for minimum 5 years

• Security updates prioritized

• Critical bug fixes backported

• Documentation maintained

Version Migration

• Migration guides provided for major versions

• Deprecation notices in minor versions

• Breaking changes documented thoroughly

Version Examples

Valid Version Numbers

1.0.0         # Stable release
1.0.1         # Patch release
1.1.0         # Minor release
2.0.0         # Major release
1.0.0.post1   # Post-release fix
1.1.0.alpha1  # Alpha release
1.1.0.beta2   # Beta release
1.1.0.rc1     # Release candidate
1.2.0.dev1    # Development version

Version Progression

Documentation Requirements

We would provide:

Major Releases

• Complete documentation update

• Migration guide

• Breaking changes list

• New features guide

Minor Releases

• New features documentation

• Deprecation notices

• Upgrade guide

Patch Releases

• Bug fix descriptions

• Security advisory if applicable

• Update instructions