Ruby 버전 업그레이드 타이밍, 릴리스 사이클로 결정하는 전략

Context

Ruby 3.2 버전의 End-of-Life(EOL) 도래. Ruby 3.3 버전의 Security-only maintenance 전환. 보안 취약점 CVE-2026-27820 대응 및 버전 관리 체계 정립 필요.

Technical Solution

• MAJOR.MINOR.TEENY 체계의 버전 관리 전략 적용. MAJOR 버전은 성능 및 기능적 도약(3x 성능, Ractor, ZJIT) 시점에 결정하는 방식.
• 매년 12월 25일 신규 MINOR 버전 출시 후 약 3년의 브랜치 생명주기 운영.
• 'Normal maintenance(2년) → Security maintenance(1년) → EOL' 순의 단계적 지원 종료 프로세스.
• 브랜치 관리자 역할을 세분화하여 최신 안정 버전, 유지보수 버전, 보안 패치 버전으로 분리 운영하는 구조.
• GitHub PR을 통한 직접 기여 및 bugs.ruby-lang.org 티켓 기반의 Backport 요청 프로세스 구축.

Key Takeaway

엄격한 Semantic Versioning 대신 언어의 진화 단계와 커뮤니티의 판단을 우선하는 유연한 릴리스 사이클 설계. 지원 종료 단계의 명확한 정의를 통해 사용자에게 예측 가능한 업그레이드 경로 제공.