그런데 실제로 이를 조건 분기로 구현해보면 상당히 복잡해진다. 더 일반화된 방법이 필요하다. 버전 관계를 다시 정의해보자. 변환기를 기준으로 생각해보면 모든 버전 사이에 순서가 있다고 할 수는 없다. 버전을 poset으로 모델링해보면 어떨까? a ≺ b 관계가 성립하는 경우에는 b의 변환기를 이용해 a를 마이그레이션할 수 있다. 이 관계가 성립하려면 (1) a가 안정 버전이고, (2) b가 알파 버전이 아니고, (3) major(a) < major(b)이어야 한다.

(1.x, 3.x)는 모든 조건을 만족하기 때문에 변환기를 거쳐 마이그레이션할 수 있다. (1.x, 3.x-beta)도 모든 조건을 만족한다. 반면 (3.x-beta, 1.x)는 (1), (3)을 위반하기 때문에 변환기를 사용할 수 없다. (2.x-alpha.1, 3.x-alpha.0)는 (1), (2)를 위반한다. 이렇게 출발 버전부터 시작해 a ≺ b 관계를 만족하고, b가 목적 버전이 아닌 경우 안정 버전이어야 한다는 조건을 적용해 나가면 도착 버전까지의 경로도 얻을 수 있다.

버전 계보를 나타내는 흐름도. 왼쪽에는 변환 가능한 버전이 세로로 배치되어 있으며, 1.x에서 시작해 2.x, 3.x, 4.x를 거쳐 5.x-beta로 순차적으로 업그레이드된다. 3.x에서 3.x-beta로의 분기와 3.x에서 4.x로의 진행이 표시되어 있다. 오른쪽에는 사각형 테두리로 묶인 영역이 있으며, 이 안에는 2.x-alpha.0에서 2.x-alpha.1로 이어지는 알파 버전 체인, 2.x-alpha.k, 그리고 3.x-alpha.0이 포함된다. 점선 화살표는 변환기가 있는 버전(2.x, 3.x)에서 변환기가 없는 알파 버전으로의 파생 관계를 나타낸다. 녹색 노드는 변환기가 있는 버전, 흰색 노드는 변환기가 없는 버전을 의미하도록 색칠되어 있다.
1

If you have a fediverse account, you can quote this note from your own instance. Search https://social.silicon.moe/users/parksb/statuses/115769688139094334 on your instance and quote it. (Note that quoting is not supported in Mastodon.)