가끔 Discourse 사이트에서 새로운 버전이 설치 가능하다는 이메일을 받곤 합니다. 그런데 매번 버전이 “x.y.z.beta something” 형식이라, Discourse가 항상 “베타” 버전인 건지 궁금합니다. 프로덕션 환경(수백 명, 어쩌면 수천 명에게 서비스를 제공하는 환경)에 설치해도 괜찮은 건가요? 아니면 무료 버전에만 해당되는 건가요?
여기서 우리가 사용하는 브랜치에 대한 좋은 설명이 있습니다:
즉, Discourse는 영구적인 베타 상태에 있으며, 이는 항상 새로운 기능과 개선 작업이 진행 중임을 의미합니다. 우리 경우 beta는 불안정하다는 뜻이 아닙니다. 월간 페이지뷰가 수백만 건에 달하는 사이트를 tests-passed 및 beta 버전으로 호스팅하고 있습니다.
@awesomerobot 님이 말씀하신 내용에 보태자면:
우리의 명명 규칙은 다른 소프트웨어 회사들과 다소 다릅니다. 우리가 베타 버전을 출시한다는 것은 새로운 증분(incremental) 버전을 출시한다는 뜻입니다. 즉, "지금으로서는 변경 사항이 충분하다. 새 업데이트에 대해 사이트들에게 통보하자"라고 말하는 것입니다.
따라서 우리에게 베타는 마이너 버전 증가(minor version bump)를, 버전은 메이저 버전 증가(major version bump)를 의미합니다. 이는 우리가 해온 작업을 기념하기 위해 스스로에게 설정하는 체크포인트입니다. 우리는 보통 연두 번의 메이저 버전을 출시하지만, 이는 기능 개발 등의 상황에 따라 달라집니다. 우리는 가짜 마감일(fake deadlines)을 두는 것을 선호하지 않습니다.
브랜치에 관하여
Stable/beta 브랜치는 tests-passed 브랜치보다 반드시 더 "안정적"인 것은 아닙니다. 여기의 핵심 개념은 버그가 알려져 있다는 점입니다. tests-passed 브랜치에서는 새로운 버그가 도입되었다가 몇 개의 커밋 뒤에 수정되는 경우가 있을 수 있습니다.
tests-passed는 보통 2주마다 작은 변경 사항을 출시하는 대부분의 다른 소프트웨어 릴리스와 크게 다르지 않습니다. 대신 우리는 거의 매일 새로운 변경 사항을 커밋하며, 이들은 tests-passed를 통해 사용할 수 있습니다.
같은 이유로 이 스레드에 참여했습니다.
설치 지침에서 왜 안정적(stable) 브랜치를 설치하라고 안내하지 않을까요?
안정적 브랜치로 변경하는 방법은 무엇이며, 현재 "더 높은 버전"을 사용 중이므로 이미 늦은 건가요?
지침을 업데이트할 수 있을까요?
이미 늦었다면, 안정적 브랜치가 업데이트될 때 그 브랜치를 유지하려면 어떻게 해야 하나요?
해당 버전까지 도달할 때까지 계속 점진적으로 업데이트해야 하나요?
Stable 버전이 최신 버전까지 업데이트될 때까지 Stable로 전환할 수 없습니다. Discourse는 다운그레이드를 지원하지 않습니다.
더 좋은 질문은 다음과 같습니다. 왜 Stable 버전으로 전환하고 싶은가요?
Stable 버전은 널리 사용되지 않으며, 개발의 초점은 테스트 통과(tests-passed)에 맞춰져 있습니다.
프로덕션 사이트를 무작정 업그레이드하지 않고 배포 전에 각 업그레이드를 테스트한다고 가정하면, 가장 기능이 풍부하고 잘 지원되는 릴리스는 기본 버전이 될 것입니다.
죄송합니다. 아마도 언어 장벽으로 인한 오해인 것 같은데, 여기서 초점(focus) 이라는 표현은
- Discourse 자체의 개발 및 브랜치 빌드 방식
- 다른 모든 사람들이 주로 Discourse 개발을 수행한다는 의미
중 어느 것을 의미하는 건가요?
전자의 경우, 기능적이고 안정적인 포럼에 초점을 맞춘 프로덕션 사이트는 test-passed를 사용해야 한다는 뜻이 됩니다.
후자의 경우, 코딩이 아닌 포럼 운영(프로덕션)에 초점을 맞춘 사이트는 stable을 사용해야 한다는 뜻이 됩니다.
네. 영어 수업을 정말 절실히 필요로 합니다. 이러한 뉘앙스가 제게는 완전히 명확하지 않기 때문입니다.
하지만 첫 번째 추측이 맞다면, stable 브랜치가 사용되지 않도록 설계된 것이 아니라면 왜 존재하는 건가요?
우리는 호스팅 환경에서 프로덕션에 tests-passed를 실행합니다. 이는 프로덕션 사이트를 위해 100% 설계된 것입니다.
Stable은 모든 소프트웨어 버그가 알려진 상태라는 것을 의미합니다. 다음 stable 버전이 릴리스될 때까지 새로운 것(새로운 버그도, 버그 수정도)을 받지 않습니다. 이는 단순히 사이트 운영자의 선호도에 따른 것입니다. 기능이 나오는 대로 사용하고 싶다면 tests-passed를 사용하세요. 메이저 버전 업데이트를 제외하고는 절대 변하지 않는 완전히 안정적인 빌드를 원한다면 stable을 사용하세요.
그 말에 이렇게 덧붙이고 싶다. “버그이지만 보안 위험으로 판단되지 않아 수정이 지연되는 문제를 6개월에서 8개월이나 기다릴 의향이 있나?” stable을 사용하세요.
그것은 완전히 사실만은 아닙니다. 안정화 버전으로 역포트된 버그 수정이 많습니다.
글쎄, 틀린 말은 아닐 거예요.
하지만 과장은 최고의 방법이에요!
맞아요, 치명적인 버그들은요. 작은 버그들은 아닙니다.
일반적인 지침에 LibreOffice 다운로드 선택지나 Debian처럼 선택할 수 있는 옵션이 있다면 좋겠습니다.
저는 DO(DigitalOcean)에서 사이트를 호스팅하고 있지만, 공동 소유자는 원래 discoursehosting.net의 서브도메인으로 시작했습니다. 그는 이 모든 유지보수를 보고 "왜 그냥 discourse hosting을 쓰지 않지?"라고 합니다.
저는 우리가 자체 도메인, 서버, 그리고 더 높은 등급의 플러그인(이모지 좋아요, Google 로그인 등)을 갖추고 있으며 다른 여러 이점도 있다고 설명했습니다. 또한 그는 아마도 구버전의 discourse를 사용하면서 업데이트도 하지 않았을 것이라고 말했습니다.
저도 안정판(stable)을 사용하다가 6개월 뒤에나 신경 쓰는 방식을 더 선호합니다. 저는 매일 Ubuntu를 사용하지만, 몇 가지 빌드 명령어를 입력할 때마다 약간 긴장됩니다. 게다가 재빌드할 때 서버가 5분 동안 중단되기도 합니다.
반면에 백업 기능이 통합되도록 요청할 계획이며, 이를 위해 베타 버전을 바로 사용할 의향이 있습니다 
추측을 피하기 위해 명확히 하자면: Communiteq(구 discoursehosting.net)에서는 고유한 호스트 이름을 제공하고, Professional 플랜 이상에서는 원하는 플러그인을 사용할 수 있으며, 포럼의 백업과 업데이트도 대신 해 드립니다. 따라서 네, 대부분의 문제는 관리형 호스팅을 사용함으로써 실제로 해결될 것입니다.
원래 이슈는 GitHub 설치 지침에서 안정적인 빌드 옵션을 제공해 달라는 것이었습니다. 고객분들을 위해 안정적인 릴리스를 제공하고 계시는 것 같습니다. 혹시 안정적인 릴리스를 클론하고 설치하는 방법에 대해 자세히 설명해 주실 수 있을까요? 제 원래 질문도 바로 이 부분이었습니다.
작고 반(半) 사적인 그룹으로서 DO의 $5 서버보다 낮은 사양을 사용할 만한 정당한 이유가 없습니다. 하지만 전문 플랜 또는 기본 플랜으로 월 $40에 훌륭한 서비스를 제공하고 계시죠. 좋은 결과가 있기를 바랍니다. 공식 Discourse 플랜과 비교하면 좋은 조건입니다. 이러한 비용을 감당할 수 있는 분들에게는 모든 옵션이 훌륭합니다. 이것이 FOSS의 가장 큰 장점입니다.
기본값으로 tests-passed 시 설치하도록 한 결정은 의도적인 것이라고 생각합니다.
새로운 설치 환경을 단일 소프트웨어 수준에서 지원하는 것이 훨씬 쉽습니다. 여기에서 제공되는 지원은 커뮤니티 기반이며 대부분 100% 무료이므로, 이를 복잡하게 만들 그럴 만한 이유가 없습니다.
표준 설치 지침이 단순화된 데에는 이유가 있습니다.
stable을 실행하는 것은 고급 설정으로 간주되므로, app.yml 파일을 수동으로 편집해야 합니다. "version"을 검색하면 해당 부분에 대해 문서화된 내용을 확인하실 수 있습니다.
discourse-setup을 수정하여 이 옵션을 포함하는 것은 대부분의 사용자에게 혼란을 줄 수 있으므로, 해당 옵션이 추가되지 않을 것으로 생각합니다.
도움이 될 만한 비유를 하나 들자면, “stable” 브랜치는 디스크 기반의 Microsoft Office와 같고, “tests-passed” 브랜치는 클라우드 기반의 Office 365와 같습니다. 두 가지 모두 유효한 선택지이며, 결국 업데이트를 받지만, 기본적으로 온라인에 기반을 두고 있고 지원 팀이 작은 제품인 경우, 버그를 신속하게 테스트하고 수정할 수 있도록 사용자에게 현재 코드로 설치 환경을 업데이트하도록 지시하는 것이 더 생산적입니다. 포럼 관리자로서 버그를 보고한 후, 이를 수정하는 버전으로 업데이트하는 데 며칠, 때로는 다음 날이면 충분하다는 점은 매우 좋습니다. 그 정도로 반응이 빠른 웹 앱은 다른 곳에서 본 적이 없습니다. (모든 버그가 즉시 수정되는 것은 아니지만, 많은 부분이 그렇습니다.)
@pfaffman, 링크와 그 링크로 연결된 페이지를 확인해 보았지만, 설정을 stable로 변경하는 방법에 대한 내용은 찾을 수 없었습니다. 제가 놓친 부분이 있을까요? app.yml 파일에서 "version"을 검색하라는 말씀인가요?
하지만 test-passed에서 stable로 전환할 수 없다고 생각합니다. (커밋을 되돌려야 하고, 데이터베이스에서 일부 마이그레이션을 역방향으로 실행해야 하기 때문이죠. 물론 test-passed 버전이 최신 stable 버전보다 충분히 오래되어 이미 넘어간 상태라면 예외일 수 있겠지만요 
)
빠른 답변 감사합니다!
업데이트가 다음 stable 릴리스 사이클까지 일시 중단될 것이라고 예상했습니다.
이 부분에 대해 어떤 통찰을 주실 수 있을까요? #version 스위치를 전환하는 즉시 무엇이 변하게 되는 건가요?