최근 기본 브랜치인 "test_passed"에서 몇 가지 문제를 겪었습니다. 그래서 stable 버전으로 전환했는데, 그러자 몇 가지 멋진 기능이 사라진 것을 발견했습니다. (큰 문제는 아니지만, discourse 브랜치에 대해 더 알고 싶습니다.)
현재 활성화된 브랜치는 다음과 같습니다.
다음과 같은 조언이 있을까요?
포럼이 비교적 공격적이고 새로운 기능을 체험하고 싶다면 , xxx 브랜치를 선택할 수 있습니다.
포럼이 매우 보수적이고 항상 안정적인 작동 상태를 유지하며, 사용자 스스로도 보수적이어서 어떤 버그도 원하지 않는다면 , xxx 브랜치를 선택할 수 있습니다.
1개의 좋아요
Stephen
7월 24, 2020, 3:01오전
2
두 경우 모두 tests_passed가 일반적으로 괜찮다고 말씀드리고 싶습니다. 스테이징 환경을 갖추고 업그레이드를 적용하기 전에 릴리스를 테스트하면 업그레이드 문제를 방지할 수 있습니다.
위에서 설명하신 문제는 특정 Discourse 브랜치보다는 자체 릴리스 프로세스와 더 관련이 깊습니다.
3개의 좋아요
테스트가 통과된 후 업데이트를 실행하고, 베타 릴리스 가 사용 가능할 때 업데이트하는 것을 권장합니다. 이렇게 하면 원하는 시점이나 필요할 때 유연하게 업데이트할 수 있습니다.
안정판(Stable)은 특정 경우를 제외하고는 권장하지 않습니다… 예를 들어 광범위한 커스터마이징이 필요한 경우(우리가 호스팅하는 사이트의 99%는 이 범주에 해당하지 않습니다). 안정판 릴리스 사이에는 몇 달의 간격이 있으며, 우리는 중요하거나 보안과 관련된 버그만 백포트합니다… 따라서 안정판에 사소한 버그가 있을 경우 상당한 시간 동안 그 버그와 함께 해야 할 수 있습니다.
관련된 추가 논의는 여기에서 볼 수 있습니다:
Security fixes are generally backported, yes. Critical (like, show stopping, unable to use Discourse) bugs are backported too. But many less critical bugs may not be. Backporting itself comes with risk, unintentional regressions can always occur, it forces users on stable to update, etc.
Our general recommendation is that sites follow the tests-passed branch (as is default), and update when a new release (beta) is out. There are certain cases where stable may be recommended, for example a site …
그리고 여기에서도:
Our customers follow tests-passed, but unlike Meta/try do not update automatically as soon as we commit. We update customers regularly, but not on a specific schedule. We deploy customers “as needed”. For example, if we got significant reports about a bug, or the bug is just really bad, we’ll generally deploy sites as soon as we know the bug is fixed. We’ll also do a deploy after we finish a new feature. Sometimes we’ll do a deploy due to a plugin update, which also causes Discourse to be updat…
9개의 좋아요
