GHC 업그레이드, 더 이상 어렵지 않아요!
GHC 업그레이드의 어려움으로 인해 많은 기업이 구버전을 사용 중이며, 이는 버그 수정 및 최신 기능 활용을 저해함
안정성 목표(STABILITY goal)와 기본 패키지(base package) 독립성 목표(BASE goal) 달성을 통해 업그레이드 과정을 개선 중임
base와 ghc-internal 분리, Template Haskell 안정화 등 기술적 조치를 통해 호환성 문제를 해결하고 있음
커뮤니티의 base 패키지 유지보수 참여를 통해 GHC 업그레이드 생태계 발전을 촉구함
GHC와 base 패키지의 긴밀한 결합 문제
과거 GHC 버전은 특정 base 패키지 버전에 종속되어, GHC 업그레이드 시 base 패키지 및 관련 생태계 전반의 버전 업데이트가 필수적이었습니다. 이는 수많은 패키지의 의존성 충돌을 야기하며, 안정적인 업그레이드 경로(Stable Upgrade Path)를 방해하는 주요 원인으로 지적됩니다. 이러한 강력한 결합(Tight Coupling)은 개발자들에게 상당한 유지보수 부담을 안겨주었습니다.
base와 ghc-internal 분리를 통한 안정성 확보
GHC 9.14 버전부터 base 라이브러리를 ghc-internal과 분리하여, GHC 자체의 변경 사항이 base API 안정성에 미치는 영향을 최소화했습니다. ghc-internal은 GHC와 함께 관리되는 반면, base는 독립적인 릴리스 주기와 안정적인 API를 제공합니다. 이를 통해 GHC 업그레이드 시에도 base 패키지 버전 호환성을 유지하여 패키지 수정 없이 업그레이드하는 것을 목표로 합니다.
Template Haskell API 안정화 노력
Template Haskell의 AST(Abstract Syntax Tree) 변경으로 인한 업그레이드 문제를 해결하기 위해, template-haskell-lift 및 template-haskell-quasiquoter와 같이 안정적인 API를 가진 여러 패키지로 분리했습니다. 이를 통해 대부분의 사용자는 불안정한 AST 직접 의존성을 피하고, 안정적인 인터페이스(Stable Interfaces)를 활용하여 GHC 업그레이드 시에도 호환성을 유지할 수 있게 됩니다.
커뮤니티의 base 패키지 유지보수 참여 요청
GHC 업그레이드 간소화 목표 달성을 위해, 커뮤니티의 적극적인 참여가 필요합니다. 특히 base 패키지의 독립적인 릴리스 관리와 GHC 내부 API의 base API 이관 작업에 대한 기여를 독려하고 있습니다. 이는 GHC 업그레이드 과정의 복잡성을 줄이고, 생태계 전반의 유지보수성 향상에 기여할 것으로 기대됩니다.
