알겠습니다. 제가 예상했던 방식과 거의 일치합니다. 실제로 이 경우, 적어도 중기적으로 일부 도구 지원이 있으면 좋겠습니다.
제가 이 개념을 이해하는 방식은 다음과 같습니다: 사용자는 특정 릴리스 채널(최신, 릴리스, ESR)에 있으며, 일반적으로는 다음 릴리스로 비교적 빠르게 전환하게 됩니다. 따라서 새 릴리스가 사용 가능하다는 메시지/알림을 받고, 이를 전환하기 위한 단일 명령을 사용할 수 있으면 좋겠습니다. 또한 새 릴리스 도입을 지연시킨 경우, 현재 사용 중인 릴리스가 더 이상 지원되지 않거나 구식이 되었을 때 알림을 받을 수 있으면 좋겠습니다. 해당 도구가 릴리스 채널도 빠르게 전환할 수 있게 해준다면 더 좋겠습니다.
하지만 현재 이것이 최우선 순위가 아니라는 점, 그리고 여전히 테스트를 통과한 최신 버전(test-passed/latest)을 유지할 것을 권장한다는 점은 이해합니다.
알겠습니다. 제 업무 맥락에서는 고객에게 기능을 배포하는 것이 "빠르다"고 여겨집니다.
또한 위에서 언급했듯이, 분기별 일정으로 전환하면 유지보수해야 할 브랜치가 줄어들어 여러분의 삶(그리고 플러그인/테마 개발자의 삶)이 더 쉬워질 것이라고 생각했습니다. 만약 그렇지 않다면, 당신들에게는 정말로 의미가 없는 것 같습니다.
SemVer 자체는 대규모 애플리케이션을 위해 특별히 설계된 것이 아닙니다. 소프트웨어에서 소비되는 라이브러리를 더 많이 대상으로 한다고 이해하고 있으며, 특히 버전 번호 체계는 패키지의 API를 중심으로 구축되어 있습니다.
다만, 우리는 SemVer를 API에 적용할 수는 있습니다. Discourse가 노출하는 API에 대해 더 강력한 보장을 갖는 것은 분명히 가치가 있는 논의이지만, 이는 이번 주제와 별개라고 생각합니다.
이제, SemVer에 준수해야 한다고 말씀하신 것이 아니라, SemVer에서 지정된 번호 체계에 부합하는 _숫자_를 계속 사용해야 한다고만 말씀하신 것임을 이해합니다.
일반적인 버전 번호는 X.Y.Z 형식을 가져야 하며, 여기서 X, Y, Z는 음이 아닌 정수여야 하고, 앞선 영숫자(leading zeroes)를 포함해서는 안 됩니다. X는 메이저 버전, Y는 마이너 버전, Z는 패치 버전을 나타냅니다. 각 요소는 수치적으로 증가해야 합니다. 예를 들어: 1.9.0 → 1.10.0 → 1.11.0.
저는 우리가 그 방향으로 간다면, "앞선 영숫자"에 대한 제안이 우리가 벗어나게 될 유일한 부분이라고 생각합니다.
그 외에는, 우리가 제안하는 버전 번호를 어떤 SemVer 라이브러리도 여전히 올바르게 파싱하고 정렬할 수 있을 것이라고 생각합니다.
이 모든 것을 제쳐두고, SemVer 번호 체계에 준수하는 것이 왜 가치가 있다고 생각하시는지 더 자세히 공유해 주시겠습니까?
SemVer의 핵심은 버전 번호가 유용한 정보를 전달해야 한다는 것입니다. 귀하가 제안한 방식에서 전달되는 유일한 정보는 지구가 태양을 도는 궤도뿐입니다. 이는 소프트웨어 사용자에게 매우 유용하지 않은 정보입니다.
만약 어떤 이유로 출시 날짜를 알고 싶다면, 출시 기록을 확인하여 정확한 날짜를 얻으면 됩니다.
그렇지 않습니다. 핵심은 릴리스의 성격을 사용자에게 전달하는 것입니다.
릴리스가 패치 버전 증가(patch version bump)인 경우, 이는 변경 사항에 소프트웨어 사용자의 워크플로우에 영향을 미칠 것으로 예상되는 내용이 포함되어 있지 않음을 전달하는 것입니다.
릴리스가 마이너 버전 증가(minor version bump)인 경우, 이는 변경 사항에 사용자 대상 새로운 컴포넌트가 추가되었지만, 소프트웨어 사용자의 기존 워크플로우를 깨뜨리는 내용은 포함되지 않음을 전달하는 것입니다.
릴리스가 메이저 버전 증가(major version bump)인 경우, 이는 변경 사항에 소프트웨어 사용자의 기존 워크플로우를 깨뜨릴 수 있는 변경 사항이 포함되었음을 전달하는 것입니다.
어떤 버전 컴포넌트를 증가시킬지 결정하는 것은 단일 사용자 인터페이스를 가진 소프트웨어 제품에서 더 명확하지만, Discourse와 같이 다양한 수준의 인터페이스와 유형의 소비자(예: 플러그인 개발자, API 소비자, 포럼 스태프, 최종 사용자)가 있는 소프트웨어 제품에서도 원칙은 동일하게 유지됩니다.
이 소프트웨어 프로젝트에서 어떤 컴포넌트를 증가시킬지 선택하는 것이 다소 주관적일 수 있지만, 여전히 귀하의 제안처럼 단순히 임의의 숫자가 아니라 버전 번호에 의미가 부여됩니다.
semver와 달리, 제안된 버전 번호 체계는 해당 버전이 여전히 지원되는지(예: Ubuntu)를 즉시 명확하게 보여줍니다. 이는 지구의 태양 공전에도 의존하므로, 실제로는 의미가 있습니다.
이것은 명확하게 패키지나 라이브러리를 대상으로 하고 있습니다. 모든 Discourse 릴리스에는 소프트웨어 사용자의 기존 워크플로를 깨뜨릴 수 있는 변경 사항이 포함됩니다. 심지어 보안 패치에서도 그런 일이 있었던 것을 본 적 있습니다. Semver은 복잡한 애플리케이션에 사용할 수 없습니다.
누락될 수 있는 점을 강조하고 싶습니다. 저는 Discourse가 이 부분에서 잘하고 있다고 생각합니다. 한 가지 개선 사항은 해당 업그레이드 사이클 내에서 변경 사항과 잠재적인 깨짐(breakage)을 설명하는 이미 작성된 주제들을 최소한 하이라이트하는 것입니다. 예를 들어, 3.5 릴리스의 경우 릴리스 노트를 열고 블로그로 이동한 후, Discourse 코어에 플러그인을 번들링하는 것에 대한 링크를 우연히 클릭해야만, 설정 파일에 해당 플러그인을 남겨두면 업그레이드에 영향을 미칠 수 있다는 세부 사항을 알아낼 수 있었습니다.
ESR 릴리스의 경우, ESR 업그레이드를 수행하기 전에 검토해야 하는 기존 주제에 대한 링크 모음이더라도, 이러한 유형의 노트를 페이지/주제로 분리해 내는 것이 좋을 것입니다.
이것은 이 스레드의 범위를 벗어날 수 있지만, 버전 관리 변경 사항에 대한 제 피드백은 이를 환영하며 여기의 투명성을 높이 평가한다는 것입니다. 저는 이것이 더 많은 셀프호스팅 옵션을 제공하면서 일을 단순화하는 훌륭한 개선이 될 것이라고 생각합니다.
라이브러리든 더 큰 애플리케이션이든 사실 큰 차이는 없습니다. 시맨틱 버전 관리(such as semver) 방식은 대형 애플리케이션에도 완벽하게 잘 작동합니다. 플랫폼으로 번들링된 애플리케이션 모음에도 사용할 수 있지만, 이 경우 적용하기가 꽤 어려워집니다.
주된 질문은 특정 릴리스에서 지원되는 비추천(deprecation) 기능을 도입하고, 다음 메이저 버전에서만 이를 제거하는 경로를 선택하는 것이냐는 것입니다. 비추천되었지만 여전히 지원되는 기능을 유지하는 것은 상당한 노력이 필요합니다. 영속 데이터 모델(persisted data model)을 변경할 때는 비추천 처리가 아예 불가능한 경우가 많습니다. 그런 일이 발생하면 비추천 기능이 포함된 마이너 버전 릴리스조차 할 수 없으며, 즉시 다음 메이저 버전으로 넘어가야 합니다. 대형 애플리케이션이 보통 문제를 겪는 부분이 바로 여기입니다. 후방 호환성을 제공할 수 없어 3.0.0에서 3.0.1을 거쳐 4.0.0으로 건너뛰게 됩니다. 깨지는 변경(breaking changes)이 잦다면 semver을 고수하는 것이 거의 가치를 주지 못합니다.
그럼에도 불구하고, 저는 이 구성을 훨씬 더 선호합니다. 개발자에게 깨지는 변경이 있을 것이라는 점을 더 명확하게 전달할 수 있기 때문입니다. YYYY.N 방식은 개발자로서도, 관리자로서도 아무런 정보를 주지 못합니다.
그러면 질문은, 버전으로 무엇을 전달하고 싶은가에 달려 있습니다. 6개의 기능 릴리스(깨지는 변경이 있을 수도, 없을 수도 있음)를 수행하고, 6번째 릴리스마다 패치를 통해 더 긴 기간 동안 지원하며, 패치 릴리스에는 버전을 매기지 않으려면 X.Y 방식이 적합합니다. 여기서 Y=0이 더 긴 기간 동안 지원되는 버전입니다. X는 단순히 숫자입니다. 문제는 X가 연도일 경우, Y가 빠르게 월과 연관 지어지다는 것입니다. 그러면 더 긴 기간 동안 지원되는 새로운 릴리스가 항상 1월에 출시되는 걸까요? 저는 항상 어떤 Ubuntu 버전이 LTS인지 찾아봐야 해서 번거롭습니다.
그렇다면 Discourse가 단순히 현재 메이저 버전을 계속 이어가는 것은 어떨까요. 다음 장기 지원(LTS) 버전은 4.0이라고 부르고, 그 후 4.1부터 4.5까지 기능 릴리스를 진행하며, 그 다음에는 최신 장기 지원 버전인 5.0이 나온다고 가정해 보겠습니다.
이렇게 하면 메이저 이슈로 인해 릴리스가 지연되는 그 어색한 순간도 사라집니다.
롤링 패치 릴리스를 하는 대신 명시적으로 패치를 릴리스할 계획이 있다면 선택적으로 “패치” 번호를 추가할 수 있습니다. "그럼 x.y.z인데, 이건 semver 아냐?"라고 할 수 있지만, 아닙니다. semver처럼 보일 뿐, 실제로는 아닙니다. 모든 새로운 “마이너” 릴리스가 깨지는 변경을 포함할 수 있기 때문입니다. 그래서 저는 Y=0 → LTS인 X.Y 버전 방식을 유지할 것을 제안합니다.
이 토론은 좋은 방향으로 보이지 않습니다. 개발 팀이 자신들에게 적합한 새로운 버전 관리 체계를 수용하기로 결정한 것처럼 보이지만, 다른 쪽에서는 갑자기 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 지옥에 빠질 것입니다. 따라서 목표가 있는 기존 릴리스에서 정기적인 릴리스로 전환하는 방법, 그리고 어떤 목표를 릴리스에서 제외(또는 연기)할지 선택하는지 등을 명확히 하는 것이 중요해집니다. (이미 문서화되어 있을 수 있지만, 제가 그 부분을 놓쳤을 수도 있습니다.)
개발/버전 관리의 속도 사이에서你们的 논거를 공유해 주시겠습니까? 그리고 관리자들이 너무 많은 설정과 높아진 학습 곡선 아래에서 허덕이지 않도록 어떤 방안을 가지고 계신지 궁금합니다.
라이프사이클 그래프를 중앙 페이지에 표시해 주었으면 합니다. 그래야 쉽게 확인할 수 있고, 이상적으로는 EOL 테이블도 함께 제공해 주면 특정 시점에 어떤 버전이 지원 대상이고 어떤 버전이 지원이 종료되었는지 쉽게 파악하고 계획을 세울 수 있을 것입니다 (적어도 ESR의 경우).
스트림 전환:
이것은 정말 좋겠습니다 – 하지만 설치를 수행할 때 어떤 태그를 선택할 수만 있어도 큰 도움이 될 것입니다. 아니면 최소한 수동으로 진행하는 단계를 설치 문서에 포함시켜 주셔도 됩니다. 안정판/ESR로 시작하고 싶은 경우, 현재 신규 관리자에게는 어떻게 해야 하는지 명확하지 않습니다. (답변은 ./launcher에 --skip-rebuild를 전달한 후 버전을 수정하고, 처음에 rebuild를 실행하는 것이라고 생각하지만, 확신은 없습니다.) 그렇지 않으면 설치가 최신 버전을 가져와서 실행하는 것으로 바로 진행되므로, 이후로 되돌아가는 것은 문제가 생길 가능성이 높습니다.
(신규 관리자가 겪는 어려움의 예: 현재 “install discourse stable”로 검색했을 때 1위 검색 결과는 이 스레드로 연결되며, 이 스레드는 안정판으로 업그레이드하는 방법을 설명하는 다른 스레드를 링크하지만, 처음부터 안정판을 설치하는 방법은 설명하지 않습니다.)
