내부적으로 “업데이트 디스코스” 페이지를 개선할 방법에 대해 몇 가지 아이디어를 논의하고 있습니다.
그중 하나는 업데이트의 이력을 표시하고, 각 업데이트 간 차이점(deltas)에 대한 변경 사항 기록(changelog) 링크를 제공하는 것입니다. (업데이트 후 관찰되는 변경 사항을 이해하는 데 도움이 될 수 있습니다.)
최근 떠오른 다른 아이디어/불만 사항들도 몇 가지 있습니다:
여러분은 어떤 다른 아이디어가 있으신가요?
2개의 좋아요
안녕하세요,
제가 계속 떠올리는 아이디어가 있습니다. '커밋할 때마다 새 버전이 있습니다’라는 알림이 짜증나는 이유는 대부분 latest 채널이 지속적으로 업데이트되기 때문입니다. 즉, 몇 개의 커밋이 뒤처져 있는 것이 사실은 정상적인 상태인데, 페이지에서는 뭔가 잘못되었 것처럼 취급하고 있거든요. 그래서 전체를 다시 설계하기보다는, 신호(중요한 알림)와 노이즈(무의미한 알림)를 구분하는 데 초점을 맞추는 것이 좋겠습니다.
제가 상상하는 방식은, 사용자가 실제로 어떤 상태에 있는지 여부에 따라 의미가 변하는 하나의 상태 배너를 사용하는 것입니다:
- 최신 상태 (Up to date) → 조용하고 긍정적이며, 행동 요구가 없음.
latest보다 몇 개의 커밋 뒤처져 있음 → 회색/정보 제공용으로, 조치가 필요하지 않음을 명시적으로 표시. 현재는 크게 떠들어 대지만, 사실은 그럴 필요가 없는 상태입니다.- 새로운 월간 릴리스가 예정되어 있음 (예:
v2026.8.0) → 눈에 띄게 표시하며, 릴리스 노트 링크 포함. - 보안 업데이트 → 빨간색/긴급하게, 단독으로 강조 표시.
마지막 두 가지 경우에만 사용자가 조치를 취해야 한다는 느낌을 줘야 합니다.
페이지에 포함하고 싶은 다른 사항들:
- 버전 번호를 다시 중심에 배치. 설치된 버전, 커밋 해시, 채널(예:
v2026.8.0-latest.1 · dfe770d · latest)을 보여주는 작은 카드 하나면 됩니다. 제가 본 가장 흔한 불만 사항이며, 복원하기도 저렴합니다. - 이미 가지고 있는 캐시된 확인 기능을 활용. 버전 확인은 이미 요청마다 실시간으로 실행되는 것이 아니라 주기적인 Sidekiq 작업으로 실행되므로, 페이지가 느리게 느껴질 필요가 없습니다. 로딩 시 재계산되는 것처럼 보이기보다는, 캐시된 결과를 즉시 렌더링하고 '마지막 확인: X분 전’이라는 문구와 수동 ‘지금 확인’ 버튼을 제공하면 됩니다.
- 체인지로그 링크가 포함된 업데이트 이력. 기본적으로 이 토픽의 원래 아이디어입니다. 월간 + ESR 릴리스의 짧은 타임라인으로, 각각 체인지로그나 diff로 링크되도록 합니다.
컴포넌트와 재빌드(rebuild)에 대해: 웹 업데이트기가 스스로 적용할 수 있는 업데이트(핵심 + 플러그인, git pull을 통해)와 컨테이너를 변경하여 명령줄에서 ./launcher rebuild app가 필요한 업데이트 사이의 구분을 가장 명확히 하고 싶습니다. 각 행에 해당 버킷(구분)이 무엇인지 표시되는 컴포넌트별 목록이 큰 도움이 될 것이며, 재빌드가 필요한 경우 추측하게 두지 말고 복사 버튼과 함께 정확한 명령어를 표시할 수 있습니다.
플러그인 호환성에 대해: .discourse-compatibility 메커니즘은 이미 코어가 플러그인이 현재 타겟으로 하는 것보다 구버전인 경우를 처리합니다. 재빌드 중에 해당 플러그인의 마지막 호환 커밋을 조용히 체크아웃합니다. 이는 주로 stable/ESR 설치에 영향을 미치며, 현재는 조용히 실행됩니다. 구버전 릴리스를 사용하는 관리자가 플러그인이 최신 커밋이 아닌 이유를 볼 수 있도록 '호환 가능한 버전으로 유지됨’이라는 단순한 정보 제공 문구로 표면화하면 좋겠습니다. (반대 경우, 즉 새로운 코어를 아직 지원하지 않는 플러그인의 경우, 현재는 제대로 처리되지 않습니다. 최소/최대 호환 버전 관련 공개된 기능 요청이 이를 커버할 것입니다.)
서로 다른 상태가 나란히 어떻게 느껴지는지 보기 위해 간단한 인터랙티브 목업을 만들어 보았습니다. 솔직히 가장 큰 이점은 '뒤처져 있지만 괜찮다’는 상태를 만드는 것입니다. 그 상태가 더 이상 경고가 되면, 페이지가 다시 진정으로 유용해집니다. 목업을 보고 싶으신 분이 계신다면 공유할 수 있습니다.
4개의 좋아요
좋습니다.
이 부분에 대해 한 가지 설명을 드리겠습니다:
저는 이것이 우리가 만드는 "릴리스"보다는 사용자가 수행한 업데이트에 관한 내용이라고 생각합니다.
즉, 업데이트를 할 때마다 새로운 행이 추가됩니다. 이는 하나의 릴리스 내의 5개의 커밋에 대한 것이거나, 다음 ESR 생성 후 첫 패치 릴리스를 기다렸다가 업데이트한 경우처럼 2026.1.6 → 2026.7.1과 같은 기간을 커버할 수도 있습니다.
어쨌든, 이는 사용자가 이전에 자신의 사이트에 대해 수행한 업데이트의 역사와 그 사이의 변경 사항을 보여줄 것입니다.
1개의 좋아요
먼저 백업의 중요성에 대해 눈에 잘 띄는 내용을 추가하세요!
업데이트가 실패할 경우, 다음 단계로 CLI에서 런처를 재구성(rebuild)하는 방법에 대한 설명도 추가해 주세요. 업데이트가 가끔 실패할 수 있으며, 이로 인해 포럼이 오프라인 상태가 될 수 있다는 점에 대한 참고 사항도 포함해 주세요.
이상적으로는, 대기 중인 변경 사항에 데이터베이스 버전 업그레이드와 같은 주요 사항이 포함되어 있음을 알리는 방법이 필요합니다. 최근 발생한 데이터베이스 버전 업그레이드는, 제가 기억하기로는, 지원 관련 주제 수가 많았던 상당히 큰 사건이었거든요.
4개의 좋아요
아, 네 말이 맞아요. 내 표현보다 훨씬 좋은 표현이네요. 저는 당신의 릴리스 목록을 상상하고 있었지만, 이 웹사이트에서 실제로 수행된 업데이트의 기록이 훨씬 더 유용하죠.
각 행은 업데이트 이벤트를 나타내며, 어디서 어디로 전환되었는지(→)와 그 사이에 어떤 체인지셋이 있었는지를 보여줍니다. 이는 물론 두 가지 경우 모두를 포괄합니다: 몇 개의 커밋으로 이루어진 채널 내의 작은 버전 업데이트이거나, 다음 ESR 버전이 출시된 후 첫 패치를 기다리던 사용자가 ESR로 전환할 때처럼 v2026.1.6 → v2026.7.1과 같은 큰 점프일 수 있죠.
4개의 좋아요