jychoi4
24b624301c
Document package formats, release workflows, deployment planning and UI concepts. Closes #1
51 lines
4.8 KiB
Markdown
51 lines
4.8 KiB
Markdown
# 버전과 GUID 관리
|
|
|
|
2026-10-19 실행 범위 변경: 1차는 MSIX identity와 4부분 버전 이력이다. 아래 MSI GUID·MSP 규칙은 후속 EXE 계약이다. [현재 설계](12-msix-first-builder.md) 참조.
|
|
|
|
아래 MSI 3부분 버전·GUID·MSP 계열은 EXE 백엔드 계약이다. MSIX는 Name/Publisher/Architecture와 4부분 Version을 별도 관리하고 Store 대상 추가 규칙을 검증한다. 제품 표시 버전에서 두 형식으로의 매핑은 명시적으로 설정한다. [범용 출력 계약](11-generic-exe-msix-architecture.md) 참조.
|
|
|
|
## 서로 다른 버전의 구분
|
|
|
|
| 값 | 목적 |
|
|
| --- | --- |
|
|
| productVersion | MSI의 3자리 버전. 예: `1.14.0` |
|
|
| displayVersion | 사용자 표시용 버전. 사전 배포 표기 허용 |
|
|
| engineVersion | 제품이 사용하는 엔진 버전. 현재 대상 `14.1` |
|
|
| PE FileVersion / ProductVersion | 실제 실행 파일에 들어 있는 버전 |
|
|
| releaseId / buildId | 릴리스/빌드 시도의 고유 식별자 |
|
|
| project schemaVersion | 생성기 설정 파일 형식의 버전 |
|
|
|
|
MSI ProductVersion은 처음 세 필드만 비교하며 최대값은 각각 255, 255, 65535다. 네 번째 필드만 바꾼 릴리스를 새로운 MSI 업데이트로 처리하지 않는다. [Microsoft ProductVersion](https://learn.microsoft.com/en-us/windows/win32/msi/productversion)
|
|
|
|
앱 버전과 엔진 `14.1`을 동일시하지 않는다. 기존 `.ism`의 `1.13.1.0`도 MSI 비교 관점은 `1.13.1`이다. 기존 업데이터는 실제 Grimi.exe 버전을 참조하므로 생성 전에 목표 릴리스와 EXE 버전의 매핑을 검사한다. 이미 빌드한 PE의 버전을 생성기가 임의 수정하지 않는다. 불일치는 제품 재빌드 또는 명시적으로 승인된 버전 매핑으로 해결한다.
|
|
|
|
## 식별자 수명
|
|
|
|
| 식별자 | 정책 |
|
|
| --- | --- |
|
|
| productId | 업데이트 서비스 제품 키. 기존 `E901`; MSI GUID와 별개 |
|
|
| UpgradeCode | 동일 제품 업그레이드 계열에서 유지 |
|
|
| ProductCode | 최초/major upgrade 시 신규; minor upgrade 패치 계열에서는 유지 |
|
|
| PackageCode | 내용이 바뀐 MSI마다 신규; 같은 확정 파일 재배포는 유지 |
|
|
| Component GUID | 같은 컴포넌트 규칙을 지키는 동안 유지 |
|
|
| PatchCode | 새 MSP마다 신규; 동일 파일 재배포는 유지 |
|
|
| Patch family / sequence | 같은 제품 패치 순서와 대체 관계를 명시적으로 관리 |
|
|
| Bundle UpgradeCode | 번들 업그레이드 계열에서 유지; MSI UpgradeCode와 별개 |
|
|
| Bundle id / version | 실제 Burn 출력에서 추출하고 탐지·등록 정책에 맞게 관리 |
|
|
|
|
Major/Minor는 앱 버전의 첫째·둘째 숫자를 의미하지 않고 Windows Installer의 업데이트 종류다. 변경된 MSI는 새 PackageCode를 가져야 하며 ProductCode 유지 여부는 업데이트 종류에 따른다. [Windows Installer 업데이트 구분](https://learn.microsoft.com/en-us/windows/win32/msi/patching-and-upgrades)
|
|
|
|
## EG-BIM 초기 전환
|
|
|
|
기존 ISM에서 확인한 UpgradeCode는 `{E6381427-A8BC-4506-A428-CE860BDA119F}`, ProductCode는 `{FBEE188C-7D40-4CBD-80DA-89919B116F57}`이다. 이것은 확인한 파일의 값이며 모든 실제 설치본이 동일하다는 보장은 없다. 출시된 설치 파일들의 식별자·언어·아키텍처를 수집해 전환 목록을 확정한다.
|
|
|
|
초기 설계는 기존 UpgradeCode 유지와 새 ProductCode를 사용하는 전체 전환이다. 기존 제거 CustomAction이 데이터까지 지울 수 있으므로 GUID 연계만으로 전환을 허용하지 않는다. 백업 위치, 실제 삭제 범위, 제거 순서와 복원 시험이 통과해야 전환 경로를 활성화한다. [기존 전환 계획](../plan/02-installer-migration.md)
|
|
|
|
## 편집과 자동 할당
|
|
|
|
화면에서 표시명·버전·UpgradeCode를 설정할 수 있지만, 첫 정식 릴리스 이후 계열 식별자는 잠근다. 새 제품/계열 생성은 기존 프로젝트를 덮어쓰지 않고 명시적인 새 계열 작업으로 처리한다. ProductCode/PackageCode/PatchCode는 엔진이 계획 단계에서 할당하고 화면에는 변경 이유를 보여 준다.
|
|
|
|
정식 빌드의 GUID를 매번 무작위로 모두 재생성하지 않는다. 실행 전에 identity lock revision과 계획된 값을 예약한다. 실패한 작업의 예약 이력은 남기고, 재개 시 동일 바이트 산출물은 재사용한다. 내용을 바꿔 다시 만드는 MSI/MSP는 새 패키지 식별자를 할당한다.
|
|
|
|
동일 버전으로 서로 다른 파일을 정식 배포하는 것은 기본 금지다. 시험 빌드는 별도 draft buildId로 구분하되 배포 등록을 허용하지 않는다. 사용자 그룹은 버전/GUID를 바꾸는 이유가 아니다. 개발자 테스트를 통과한 동일 파일을 다음 그룹으로 승격한다.
|