|
| 1 | +--- |
| 2 | +title: 소프트웨어 생명 주기 |
| 3 | +name: software-life-cycle |
| 4 | +id: ko-software-life-cycle |
| 5 | +permalink: /ko/lifecycle/ |
| 6 | +layout: page |
| 7 | +type: pages |
| 8 | +lang: ko |
| 9 | +version: 1 |
| 10 | +--- |
| 11 | + |
| 12 | +{% include toc.html %} |
| 13 | + |
| 14 | +이 문서는 Bitcoin Core 프로젝트가 배포하는 Bitcoin Core 소프트웨어 패키지의 생명 주기를 설명합니다. |
| 15 | +전반적인 정책은 일반적인 상용 소프트웨어 유지보수 정책과 유사한 원칙을 따릅니다. |
| 16 | + |
| 17 | +## 버전 관리 |
| 18 | + |
| 19 | +Bitcoin Core 릴리스 버전은 `MAJOR.MINOR` 형식을 따르며, 릴리스 후보는 `rc1`, `rc2`처럼 표기합니다. |
| 20 | + |
| 21 | +프로젝트는 약 6개월마다 메이저 릴리스(예: `29.0`, `30.0`)를 목표로 합니다. |
| 22 | + |
| 23 | +각 메이저 릴리스에는 버그(보안 포함) 수정 목적의 마이너(유지보수) 릴리스를 제공합니다. |
| 24 | +유지보수 릴리스는 `29.3`, `30.1`처럼 표기되며, 원칙적으로 대규모 신규 기능은 포함하지 않습니다 |
| 25 | +(합의 규칙 변경은 아래 별도 정책 참고). |
| 26 | + |
| 27 | +## 합의 규칙 |
| 28 | + |
| 29 | +합의 규칙 변경 제안은 일반적으로 `22.2`, `23.1` 같은 유지보수 릴리스에 먼저 포함됩니다. |
| 30 | +이 방식은 메이저 릴리스보다 변경 범위가 작아 엔터프라이즈 사용자가 평가/테스트하기 쉽고, |
| 31 | +보수적인 업그레이드 정책을 따르는 사용자도 합의 규칙 변경을 비교적 적시에 반영할 수 있게 합니다. |
| 32 | + |
| 33 | +## 유지보수 기간 |
| 34 | + |
| 35 | +프로젝트는 항상 최신 메이저 버전 3개를 유지보수합니다. |
| 36 | +새 메이저 릴리스가 나오면 가장 오래된 메이저 버전은 유지보수 대상에서 제외되어 "End of Life(EOL)"가 됩니다. |
| 37 | + |
| 38 | +예: 최신 메이저가 `30.0`이면 `29.x`, `28.x`도 유지보수 대상입니다. |
| 39 | +이후 `31.0`이 릴리스되면 `28.x`는 EOL이 됩니다. |
| 40 | +버전이 오래될수록 변경사항을 백포트(backport)하는 기준은 더 엄격해집니다. |
| 41 | + |
| 42 | +일반적으로 EOL 메이저 버전에는 보안 수정이 제공되지 않습니다. |
| 43 | +보안 정책은 [보안 권고 페이지][security advisories]를 참고해 주세요. |
| 44 | +가능하다면 업그레이드 가능한 범위에서 가장 최신 메이저 버전의 최신 유지보수 릴리스를 사용하기를 권장합니다. |
| 45 | + |
| 46 | +## 일정 |
| 47 | + |
| 48 | +EOL에 도달하면 더 최신 버전으로 업그레이드해야 합니다. |
| 49 | + |
| 50 | +{% include posts/maintenance-table.md %} |
| 51 | + |
| 52 | +\* _메이저 릴리스는 대략 6~7개월 간격을 목표로 합니다_ |
| 53 | + |
| 54 | +_TBA: 추후 공지_ |
| 55 | + |
| 56 | +## 프로토콜 버전 관리 |
| 57 | + |
| 58 | +위 설명은 Bitcoin Core 소프트웨어 릴리스 버전에 관한 내용입니다. |
| 59 | +비트코인 시스템의 다른 구성요소들은 자체 버전 체계를 가집니다. 예: |
| 60 | + |
| 61 | +- 모든 **트랜잭션**은 버전 번호를 포함합니다. |
| 62 | +- **P2P 네트워크 프로토콜**은 노드가 지원 기능을 알릴 수 있도록 버전 번호를 사용합니다. |
| 63 | +- Bitcoin Core **내장 지갑**도 자체 내부 버전 번호가 있습니다. |
| 64 | + |
| 65 | +이 버전들은 의도적으로 Bitcoin Core 릴리스 버전과 분리되어 있습니다. |
| 66 | +이는 블록/트랜잭션처럼 프로젝트가 직접 통제하지 않는 경우가 있고, |
| 67 | +네트워크 프로토콜처럼 다른 프로젝트와의 호환성을 유지해야 하는 경우가 있으며, |
| 68 | +내장 지갑처럼 일부 릴리스에서 큰 변화가 없을 가능성도 있기 때문입니다. |
| 69 | + |
| 70 | +합의 프로토콜 자체에는 별도 버전 번호가 없습니다. |
| 71 | + |
| 72 | +## SemVer와의 관계 |
| 73 | + |
| 74 | +Bitcoin Core 소프트웨어 버전 관리는 [SemVer][] 표준을 그대로 따르지는 않지만, |
| 75 | +표면적인 표기 방식은 유사합니다. SemVer는 보통 라이브러리처럼 사용자마다 |
| 76 | +업그레이드 시점을 자유롭게 선택할 수 있는 환경을 전제로 설계되었습니다. |
| 77 | + |
| 78 | +하지만 비트코인의 핵심 영역(특히 합의 규칙)은 네트워크 전반의 채택이 필요하므로 |
| 79 | +같은 방식으로 다루기 어렵습니다. 새로운 합의 규칙이 적용되려면 일정 수의 채굴자/풀노드가 |
| 80 | +이를 강제해야 하며, 새 규칙을 모르는 소프트웨어는 잘못된 트랜잭션을 생성하거나 수용할 수 있습니다. |
| 81 | + |
| 82 | +이러한 이유로 Bitcoin Core는 합의 규칙 및 네트워크 전반 채택이 필요한 변경에 대해 |
| 83 | +SemVer 관행과 다르게 동작할 수 있습니다. 해당 변경은 메이저 릴리스(`x.0`) 대신 |
| 84 | +유지보수 릴리스(`x.y`)로 배포해 패치 크기를 줄이고, 더 많은 사용자가 점검/테스트/배포하기 쉽게 합니다. |
| 85 | +또한 같은 패치를 여러 이전 메이저 버전에 백포트할 수 있어 업그레이드 가능한 사용자 범위를 넓힐 수 있습니다. |
| 86 | + |
| 87 | +[SemVer]: https://semver.org/ |
| 88 | +[security advisories]: /ko/security-advisories |
0 commit comments