Skip to main content

Electron 버전 관리

버전 관리 정책과 구현 방식에 대한 상세한 설명

Electron은 2.0.0 버전부터 SemVer 사양을 따르고 있다. 다음 커맨드를 실행하면 가장 최신의 안정적인 Electron 빌드를 설치할 수 있다:

npm install --save-dev electron

기존 프로젝트를 최신 안정 버전으로 업데이트하려면 다음 커맨드를 사용한다:

npm install --save-dev electron@latest

버전 관리 전략​

기존 1.x 전략에서 몇 가지 주요 변경 사항을 도입했다. 각 변경 사항은 개발자/유지보수 담당자와 앱 개발자의 요구사항과 우선순위를 충족시키기 위해 고안되었다.

  1. SemVer 스펙을 엄격히 준수
  2. semver 규격을 따르는 -beta 태그 도입
  3. 컨벤셔널 커밋 메시지 채택
  4. 명확히 정의된 안정화 브랜치
  5. main 브랜치는 버전 정보를 포함하지 않음. 안정화 브랜치에만 버전 정보 포함

이어서 git 브랜치 전략, npm 태깅 방식, 개발자가 주의해야 할 사항, 그리고 변경 사항을 이전 버전에 백포트하는 방법에 대해 자세히 설명한다.

SemVer​

아래 표는 변경 유형을 SemVer 카테고리(예: 메이저, 마이너, 패치)에 명시적으로 매핑한 것이다.

메이저 버전 증가마이너 버전 증가패치 버전 증가
Electron의 호환되지 않는 API 변경Electron의 호환되는 API 변경Electron의 버그 수정
Node.js의 메이저 버전 업데이트Node.js의 마이너 버전 업데이트Node.js의 패치 버전 업데이트
Chromium 버전 업데이트Chromium의 버그 수정 관련 패치

더 자세한 정보는 Semantic Versioning 2.0.0 스펙을 참고한다.

대부분의 Chromium 업데이트는 호환되지 않는 변경으로 간주된다. 백포트 가능한 수정 사항은 패치로 선별 적용될 가능성이 높다.

안정화 브랜치​

안정화 브랜치는 main 브랜치와 병렬로 운영되며, 보안이나 안정성과 관련된 커밋만 선택적으로 반영한다. 이 브랜치는 절대 main 브랜치로 병합되지 않는다.

안정화 브랜치

Electron 8부터 안정화 브랜치는 항상 메이저 버전 라인을 따르며, $MAJOR-x-y 형식으로 이름을 짓는다. 예를 들어 8-x-y와 같다. 이전에는 마이너 버전 라인을 사용했고, $MAJOR-$MINOR-x 형식으로 이름을 지었다. 예를 들어 2-0-x와 같다.

여러 안정화 브랜치를 동시에 운영할 수 있으며, 각 지원 버전마다 하나씩 존재한다. 지원되는 버전에 대한 자세한 내용은 Electron 릴리스 문서를 참고한다.

다중 안정화 브랜치

오래된 버전 라인은 Electron 프로젝트에서 더 이상 지원하지 않지만, 다른 그룹이 소유권을 가져가고 안정성 및 보안 수정 사항을 자체적으로 백포트할 수 있다. 이 방법을 권장하지는 않지만, 많은 앱 개발자에게 편의를 제공한다는 점은 인정한다.

베타 릴리스와 버그 수정​

개발자들은 어떤 릴리스가 안전하게 사용할 수 있는지 알고 싶어 한다. 겉보기에는 무해해 보이는 기능도 복잡한 애플리케이션에서 회귀 문제를 일으킬 수 있다. 동시에 특정 버전에 고정하는 것도 위험하다. 그 버전 이후로 나온 보안 패치나 버그 수정을 놓칠 수 있기 때문이다. 우리의 목표는 package.json에서 다음과 같은 표준 SemVer 범위를 허용하는 것이다:

  • ~2.0.0을 사용하면 2.0.0 릴리스에 대한 안정성 또는 보안 관련 수정만 허용한다.
  • ^2.0.0을 사용하면 주요 기능을 깨지 않는 합리적으로 안정적인 기능 작업과 보안 및 버그 수정도 허용한다.

두 번째 포인트에서 중요한 것은 ^를 사용하는 앱도 여전히 합리적인 수준의 안정성을 기대할 수 있어야 한다는 점이다. 이를 위해 SemVer는 특정 버전이 아직 안전하거나 안정적이지 않음을 나타내는 _사전 릴리스 식별자_를 허용한다.

어떤 방식을 선택하든, Chromium의 특성상 주요 변경 사항이 발생하면 주기적으로 package.json의 버전을 업데이트해야 한다.

이 과정은 다음과 같다:

  1. 모든 새로운 주요 및 부 버전 릴리스 라인은 beta.N과 같은 SemVer 사전 릴리스 태그로 시작한다. 예를 들어 2.0.0-beta.1. 첫 번째 베타 이후, 후속 베타 릴리스는 다음 조건을 모두 만족해야 한다:
    1. 변경 사항이 이전 API와 호환되어야 한다(사용 중단은 허용).
    2. 안정성 타임라인을 맞출 위험이 낮아야 한다.
  2. 릴리스가 베타 상태일 때 허용된 변경 사항이 필요하면 적용하고 사전 릴리스 태그를 증가시킨다. 예: 2.0.0-beta.2.
  3. 특정 베타 릴리스가 _일반적으로 안정적_으로 간주되면 안정 빌드로 재릴리스되며, 버전 정보만 변경된다. 예: 2.0.0. 첫 번째 안정 버전 이후 모든 변경 사항은 이전 버전과 호환되는 버그 또는 보안 수정이어야 한다.
  4. 릴리스가 안정화된 후 버그 수정이나 보안 패치가 필요하면 적용하고 패치 버전을 증가시킨다. 예: 2.0.1.

구체적으로 위 내용은 다음과 같다:

  1. 베타 주기의 3주차 이전에 API를 깨지 않는 변경 사항을 허용하는 것은 괜찮다. 해당 변경 사항이 중간 정도의 부작용을 일으킬 가능성이 있어도 마찬가지다.
  2. 베타 주기의 대부분 시점에서 기존 코드 경로를 변경하지 않는 기능 플래그 변경을 허용하는 것은 괜찮다. 사용자는 앱에서 해당 플래그를 명시적으로 활성화할 수 있다.
  3. 베타 주기의 3주차 이후에는 아주 좋은 이유 없이 어떤 종류의 기능도 허용하지 않는 것이 좋다.

각 주요 및 부 버전 업데이트에서는 다음과 같은 과정을 예상할 수 있다:

2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0
2.0.1
2.0.2

그림으로 보는 예시 라이프사이클:

  • 새로운 릴리스 브랜치가 생성되고 최신 기능이 포함된다. 이 브랜치는 2.0.0-beta.1로 릴리스된다. 새로운 릴리스 브랜치
  • 마스터에 버그 수정이 들어오면 릴리스 브랜치로 백포트할 수 있다. 패치가 적용되고 새로운 베타가 2.0.0-beta.2로 릴리스된다. 베타로 버그 수정 백포트
  • 베타가 _일반적으로 안정적_으로 간주되면 비베타 버전인 2.0.0으로 다시 릴리스된다. 베타에서 안정 버전으로
  • 나중에 제로데이 취약점이 발견되면 마스터에 수정 사항이 적용된다. 2-0-x 라인에 수정 사항을 백포트하고 2.0.1을 릴리스한다. 보안 백포트

다양한 SemVer 범위가 새로운 릴리스를 선택하는 방식의 몇 가지 예시:

SemVer와 릴리스

백포트 요청 처리 과정​

지원되는 모든 릴리스 라인은 main 브랜치에 병합된 수정 사항을 백포트하는 외부 풀 리퀘스트를 받아들인다. 다만, 일부 오래된 지원 라인의 경우 사례별로 결정할 수 있다. 릴리스 라인 백포트와 관련된 모든 논쟁은 릴리스 작업 그룹(Releases Working Group)이 백포트 풀 리퀘스트가 제출된 주의 주간 회의에서 의제로 다루며 해결한다.

기능 플래그​

기능 플래그는 Chromium에서 흔히 사용되며, 웹 개발 생태계에서도 잘 정립된 개념이다. Electron에서 기능 플래그 또는 소프트 브랜치는 다음과 같은 특성을 가져야 한다:

  • 런타임이나 빌드 타임에 활성화/비활성화할 수 있다. 요청 범위의 기능 플래그 개념은 지원하지 않는다.
  • 새로운 코드 경로와 기존 코드 경로를 완전히 분리한다. 새로운 기능을 지원하기 위해 기존 코드를 리팩토링하는 것은 기능 플래그 계약을 위반한다.
  • 기능이 출시된 후에는 기능 플래그를 결국 제거한다.

의미론적 커밋 규칙​

모든 풀 리퀘스트는 Conventional Commits 스펙을 따라야 한다. 이를 요약하면 다음과 같다:

  • SemVer 메이저 버전 업그레이드가 필요한 커밋은 본문을 BREAKING CHANGE:로 시작해야 한다.
  • SemVer 마이너 버전 업그레이드가 필요한 커밋은 feat:로 시작해야 한다.
  • SemVer 패치 버전 업그레이드가 필요한 커밋은 fix:로 시작해야 한다.

electron/electron 저장소는 스쿼시 머지를 강제하므로, 풀 리퀘스트의 제목 접두사만 올바르게 설정하면 된다.

버전 관리된 main 브랜치​

  • main 브랜치는 항상 다음 주요 버전인 X.0.0-nightly.DATE를 package.json에 포함한다.
  • 릴리스 브랜치는 절대 main 브랜치로 병합되지 않는다.
  • 릴리스 브랜치는 package.json에 정확한 버전을 포함한다.
  • 주요 버전을 위한 릴리스 브랜치가 생성되면, main 브랜치는 반드시 다음 주요 버전으로 업데이트해야 한다. 즉, main 브랜치는 항상 다음 이론적 릴리스 브랜치의 버전을 유지한다.

역사적 버전 관리 (Electron 1.X)​

Electron 버전 2.0 미만 은 SemVer 규격을 따르지 않았다. 메이저 버전은 최종 사용자 API 변경에 대응했고, 마이너 버전은 Chromium 메이저 릴리즈에 대응했으며, 패치 버전은 새로운 기능과 버그 수정을 포함했다. 이 방식은 기능을 병합하는 개발자에게는 편리했지만, 클라이언트를 상대하는 애플리케이션 개발자에게는 문제를 일으켰다. Slack, Teams, Skype, VS Code, GitHub Desktop과 같은 주요 앱의 QA 테스트 주기는 길 수 있으며, 안정성이 매우 중요한 결과물이다. 버그 수정을 흡수하면서 새로운 기능을 도입하는 것은 상당한 위험을 수반한다.

다음은 1.x 전략의 예시다:

1.x 버전 관리

1.8.1로 개발된 앱은 1.8.2 기능을 흡수하거나 수정 사항을 백포트하고 새로운 릴리즈 라인을 유지하지 않는 한, 1.8.3 버그 수정을 적용할 수 없다.