제가 아는 한 "verfified"에 대한 공식적인 정의는 없습니다.
모든 소프트웨어에는 잠재적으로 버그가 있을 수 있습니다.
tests-passed에는 가장 최신의 커밋이 포함됩니다. beta에는 베타 릴리스만, stable에는 안정 버전 릴리스만 포함됩니다.
tests-passed는 사실상 모든 discourse.org 호스팅 사이트와 대다수의 셀프호스팅 사이트에서 실행되고 있습니다.
@mcwumbly – "어떤 버전을 실행해야 하는가"에 대한 문서가 있는지요? 잠시 검색해 보았지만 찾지 못했습니다. 제가 기억하는 것은 stable 공지사항에서 본 것과 같은 내용뿐입니다.
다음은
이것이 주제에 대한 좋은 시작이 될 수 있습니다
해당 게시글은 여기에서도 인용되어 있습니다: Is Discourse always in "beta"?
그리고 이 주제도 있습니다: Switching between Discourse release channels / versions
tests-passed를 사용하도록 권장한다는 점을 더 명확하게 참조할 수 있도록, 이 주제에 대해 더 나은 설명을 담은 별도 주제를 마련해야 한다는 데 동의합니다.
그와 별개로, beta를 제거하는 것에 대해 다소 유혹을 느끼고 있습니다(이와 관련하여 새 주제를 시작할 수도 있습니다).
설치 지침(discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub)에서 빌드 간의 차이점과 현재 사용 중인 빌드를 변경하는 방법에 대해서도 설명해야 합니다. 해당 문서를 간단히 살펴봤는데, 이에 대한 언급은 찾아볼 수 없었습니다.
이 내용을 따로 분리했습니다(아마도 처음 해보는 것 같습니다!). 왜냐하면 해당 사용자는 여전히 업그레이드가 "위험한"지 판단할 수 없기 때문이며, 업그레이드해야 하는지 모르는 사람들의 문제를 해결하는 방법에 대한 이 논의는 도움이 되지 못하고 있습니다.
실제로 Updates always come before release notes - #7 by jomaxro 은 좋은 출발점이 될 수 있으며, 어쩌면 그것만으로도 충분할 수 있습니다. 적절하고 합리적인 제목만 붙여주면 됩니다.
아마도 Is Discourse always in "beta"? 가 제가 찾던 것(하지만 그곳에 있다는 것을 잊고 있었던)일 수도 있습니다.
그가 처음부터 묻고 있었고, 꽤 합리적인 질문이라고 생각하는 다른 하나는 "최신 베타 버전을 사용 중인데 왜 업그레이드가 필요합니까?"입니다. 위의 내용은 이 질문에 꽤 직접적으로 답하고 있습니다.
답변은 의외로 복잡합니다.
훌륭합니다. 제 임무는 여기서 끝났습니다. 
그렇게 해야 한다고 생각하지 않습니다. 우리는 사람들이 tests-passed를 사용하길 원합니다. 공식 설치 설명서는 우리가 원하는 설정과 최대한 일치하는 기본 설치로 안내해야 합니다. 여기에는 추적되는 브랜치도 포함됩니다.
최신 안정판(latest stable release)을 사용하기로 결정하는 사람들이 항상 있을 것입니다. 가장 직관적인 위치에 이를 위한 가이드가 없더라도 그런 사람들이 사라지는 것은 아니며, 단지 그들에게 조금 덜 편리할 뿐입니다. 그리고 이로 인해 그들이 이곳에 질문을 올리는 경우가 많아지고, 다른 사람들이 그 질문에(반복적으로) 답변하는 데 시간을 보내게 될 가능성이 높습니다.
그러나 더 강력한 논거는, 이 가이드가 올바른 방법으로 수행하는 방법을 보여줄 수 있다는 점입니다. 이는 나중에 마음을 바꿀 경우 다시 원래대로 되돌릴 수 있음을 의미합니다. 올바른 방법을 모르면 설치를 깨뜨리게 될 수 있으며, 이는 그 자신과 커뮤니티 모두에게 불편을 초래합니다.
INSTALL-cloud.md에 브랜치를 변경하는 방법에 대한 섹션이 있다면, 기본값이 무엇인지, 그리고 왜 그런지 명확히 설명할 수 있습니다. 이를 통해 기본값이 가장 널리 사용되며, 지원이 가장 쉽다는 점을 분명히 할 수 있습니다.
메타에 브랜치를 변경하는 방법에 대한 가이드가 존재하는 것에 대해 100% 찬성합니다. 다만, 공식 설치 가이드에는 95%의 사용자들이 관심도 없고 필요도 없는 정보이므로 포함되지 않는 것이 좋다고 생각합니다.
기본적인 설치만 원하는 '베이직 밥’은 가능한 빠르고 쉽게 설치를 마쳐 새 사이트를 운영하고자 할 뿐입니다. 브랜치 변경에 대한 정보는 오히려 그를 더 생각하게 만들고 혼란을 유발할 수 있습니다.
반면, '어드밴스드 앨리’는 브랜치가 어떻게 작동하는지, 그리고 어떤 브랜치가 자신의 사이트에 가장 적합한지 이해하는 데 관심이 있을 수 있습니다. 하지만 그녀는 단순히 설치 가이드를 따라가는 것이 아니라, Discourse를 설치하기 전에 더 많은 조사를 할 가능성이 높습니다.
실제로 현재 상태로는 베타 또는 안정판으로 롤백하길 원하지만 실패하는 사용자의 게시글이 가끔 올라옵니다.
표준 설치 문서에 이를 포함시키면, 위에서 언급한 문제와 이전 릴리스와의 플러그인 호환성 문제로 인해 수많은 문제들이 쏟아져 나올 것입니다.
동의합니다. 전반적으로 beta는 실용성을 제공하기보다 사람들을 더 혼란스럽게 한다고 느낍니다.
여기서 내부적으로 사용되고 의미를 갖는 것과 제3자에게 의미를 갖는 것 사이에 구분을 그리는 것이 도움이 될 것 같습니다. beta 브랜치는 이 점의 좋은 예입니다. 내부적으로 일부 유용성이 있을 수 있지만, 제3자에게는 유용성이 거의 없으며 때로는 혼란을 야기하기도 합니다.
다른 의견이 있다면 듣고 싶지만, 지금 다시 생각해 보니 beta를 의미 있는 방식으로 실제로 사용하는 심각한 자체 호스터(self-hoster)를 떠올릴 수가 없습니다. "Basic Bob"은 브랜치가 무엇인지 잘 모르고 아마도 신경 쓰지 않을 것입니다 (그리고 그것은 당연한 일입니다). "Advanced Ally"는 개인이나 중소기업(SMB)이라면 tests-passed를 사용할 것이며, 중견 또는 대기업이라면 stable을 사용하거나(또는 커밋을 고정할 것입니다) 사용할 것입니다.
제 제안은 브랜치 관련 모든 것을 현재와 동일하게 유지하되, 공개적으로 "사용할 수 있는 두 개의 브랜치가 있습니다: tests-passed(기본값이며 가장 좋습니다)와 stable(자신이 무엇을 하고 있는지 정확히 알고 특정 필요성이 있는 경우)"이라고 말하는 것입니다.
제 입장에서는, 대시보드에서 버전 이름 옆에 tests-passed 브랜치 이름만 표시되어도 충분히 개선된 것입니다.
전적으로 동의합니다. 다른 브랜치를 선택하려는 사람은 거의 항상 그 방법을 찾을 수 있을 것입니다.
기존 리소스(검색, 표준 GitHub 프로젝트)를 활용해서도 찾지 못한다면, 정말로 브랜치 간의 차이를 완전히 이해하는 데 필요한 역량을 갖추고 있는지, 더 나아가 기본값이라는 안전지대에서 벗어나는 것을 감당할 수 있는지를 의심하게 됩니다.
네, 이해가 됩니다. 하지만 여기서는 다양한 옵션 간의 차이를 이해하는 데 도움을 줄 기회를 놓치고 있는 것 같습니다. 자체 호스팅 사용자에게 기본값이 대부분의 사이트에서 이상적인 tests-passed이며, 이를 통해 최신 보안 패치와 업데이트를 받을 수 있다고 알려주는 데 해로울 것이 없다고 생각합니다. 리스크를 최소화하고 싶다면 tests-passed를 유지하고 소프트웨어에서 업데이트를 권고할 때만, 혹은 권고를 받은 후 약 1주일 후에 업데이트를 수행하면 됩니다. 이렇게 하면 다른 사용자가 먼저 문제를 발견하고, 사용자가 업데이트하기 전에 해당 문제가 수정될 수 있습니다.
위 내용을 고려할 때, 자체 호스팅 사용자가 tests-passed에서 다른 옵션으로 전환해야 할 정당한 이유가 있을까요? 아마도 사이트가 크게 수정되어(core modding) 코어 디스코urs나 공식 플러그인이 업데이트되면 깨질 수 있고, 자신이나 관리자가 업데이트를 하지 않을 것이라고 신뢰할 수 없는 경우일 것입니다. 또는 개발 또는 스테이징 환경을 설정하는 경우라면요.
이를 설명할 또 다른 장소로는 app.yml 파일이 있습니다. 현재 이 파일은 tests-passed만 언급하고 옵션이나 언제 다른 옵션으로 전환해야 하는지에 대해 언급하지 않아 다소 난해합니다.
## 이 컨테이너에 사용할 Git 리비전은 무엇인가요? (기본값: tests-passed)
#version: tests-passed
제 생각에는 tests-passed를 제외한 다른 것을 사용하는 것이 실제로 의미가 있는 경우는 다음 두 가지 조건이 모두 충족될 때입니다: 1) 커뮤니티를 관리하는 팀이 있는 경우(즉, 중대형 엔터프라이즈인 경우)이고, 2) tests-passed를 사용하지 않는 구체적인 이유가 있는 경우, 예를 들어 깨질 수 있는 여러 가지 커스텀화가 있는 경우 등입니다.
두 조건이 모두 필요하다고 생각합니다. 왜냐하면 커뮤니티를 관리하는 팀이 있는 상태에서 취약한 커스텀화가 여러 개 있는 시나리오가 아니라면, 문제의 원인은 브랜치 사용법이 아니라 사이트 전체의 관리 방식(즉, 지속 불가능한 상태)이기 때문입니다.
두 조건이 모두 참이라고 하더라도, 업데이트 정책과 같은 다른 사항들을 먼저 고려해야 합니다.
문제는 "stable 또는 tests-passed를 사용할 수 있습니다"라고 말하면, 일부 사람들이 실제로는 사용해서는 안 되는데도 '합리적’이라고 느껴서 stable을 입력하게 된다는 점입니다.
beta 브랜치에 대한 반대 논리를 강화하기 위해, 다양한 서면 및 구두 맥락에서 이 브랜치가 유발하는 주요 혼동은 다음과 같습니다:
tests-passed보다는 덜 최신적이고 stable보다는 최신이라고 느껴져 '합리적’이라고 생각하여 사용을 고려합니다. 하지만 대부분의 경우 이는 좋은 아이디어가 아닙니다.“베타”라는 단어가 저처럼 컴퓨터에 대해 어느 정도는 아는 사람들에게는 오히려 꺼림칙하게 느껴질 수 있습니다. 일반적인 의미는 “기능을 추가하는 중”이 아니라 “품질 검수를 위한 테스트 단계”이기 때문이죠.
아마도 저는 브랜치 이름보다는 버전 이름에 더 주목하고 있었던 것 같습니다. 버전 이름을 보고 제가 “베타” 브랜치에 있는 줄 알고 있었는데(사실은 아니었죠), 지금 확인해 보니 전혀 불편함을 느끼지 못했습니다…
네. tests-passed 브랜치에 있으면서 버전은 "beta"로 표시되는데, 업그레이드를 하면 이미 사용하고 있는 것과 동일한 베타 버전의 새 코드를 받게 되는 상황이 혼란스럽다고 생각합니다(혹은 혼란스러울 수 있다는 점을 이해할 수 있습니다). 게다가 베타 릴리스 사이에는 몇 주가 걸리고 수백 개의 커밋이 쌓이거든요.
위에서 언급된 토론과 자료를 반영하기 위해 이 가이드에 몇 가지 수정을 가했습니다: Switching between Discourse release channels / versions