이 토론은 좋은 방향으로 보이지 않습니다. 개발 팀이 자신들에게 적합한 새로운 버전 관리 체계를 수용하기로 결정한 것처럼 보이지만, 다른 쪽에서는 갑자기 Discourse 버전이 시맨틱 버전 관리(Semantic Versioning)를 따랐던 것처럼 주장하고 있습니다… 하지만 실제로는 그렇지 않았습니다. 적어도 1.0 버전부터는 롤링 릴리스(Rolling Release) 방식이었죠, 맞나요?
하지만 토론 양측의 논거들은 모두 결함이 있어 보입니다:
- “산업 표준”: Linux는 안정 버전(even major)과 개발 버전(odd major)을 구분하여 사용합니다.
- “지구 공전”: 음, 이슬람교로 개종하면 문제가 생길 텐데, 버전을 건너뛰게 되면 더 이상 태양의 공전 주기와 맞지 않고 달의 주기와 맞게 됩니다. 여기서 이제 X.Y.Z 대신 YYYY.Y.Z 버전 관리 방식을 선택함으로써 지배적인 문화를 강요했다는 것을 이해하게 됩니다.
- 마이너 릴리스는 여전히 불분명합니다: "월별 주기를 가정한다"고 언급하셨지만, 기능에 따라 3주나 7주도 될 수 있습니다. 이 경우 Y를 0부터 세는 것이 의미가 있을 수 있거나, 실제로 월별 릴리스를 목표로 하고 있다면 M을 1부터 세는 것이 더 의미가 있을 것입니다.
제가 보는 주요 변화는 월별 주기를 채택함으로써 Discourse 팀이 기대치를 설정하고, 릴리스 목표에서 벗어나 정기적인 릴리스를 수용하고 있다는 점입니다.
8개월의 LTS는 정말로 "장기적"이라고 느껴지지 않습니다. NodeJS는 너무 빠르게 움직이지만, 30개월 이상 LTS 지원을 유지하고 동시에 몇 가지 최신 버전을 유지합니다. 반면 Ubuntu는 수년간 LTS를 유지합니다. Discourse가 언어나 운영체제가 아니라는 점은 이해하지만, 새로운 기능이 상당히 빠른 속도로 출시될 것이라고 암시하는 것 같아 또 다른 문제가 떠오릅니다. 이제부터 때때로 새로운 관리자 설정이 도입되므로, 곧 무한한 옵션과 사이트 관리에 대한 이해할 수 없는 복잡성, 즉 볼트웨어(Bloatware)의 Wordpress 지옥에 빠질 것입니다. 따라서 목표가 있는 기존 릴리스에서 정기적인 릴리스로 전환하는 방법, 그리고 어떤 목표를 릴리스에서 제외(또는 연기)할지 선택하는지 등을 명확히 하는 것이 중요해집니다. (이미 문서화되어 있을 수 있지만, 제가 그 부분을 놓쳤을 수도 있습니다.)
개발/버전 관리의 속도 사이에서你们的 논거를 공유해 주시겠습니까? 그리고 관리자들이 너무 많은 설정과 높아진 학습 곡선 아래에서 허덕이지 않도록 어떤 방안을 가지고 계신지 궁금합니다.
