리눅스커널(Linux Kernel)의 버전관리(Versioning)

오늘은 첫 순서로 본격적으로 Kernel 코드로 들어가기에 앞서 Linux Kernel 의 버전관리가 어떻게 이루어지는지에 대해 포스팅해보고자 한다. 버전관리가 어떻게 이루어지는지를 이해하면 Linux Kernel 의 개발 Process 를 어느정도 이해할 수 있기 때문에 Kernel 을 공부하는 개발자의 상식으로라도 알아두는 것이 좋겠다.

Linux Kernel 개발 process 에 참여하고 싶거나 관심이 있는 개발자라면 아래의 Link 를 유심히 읽어볼 것을 권장한다. 개발자들이 Linux Kernel 의 개발 Process 를 반드시 이해하고 참여하도록 유도하기 위한 문서이다. 이러한 Process 를 이해하지 못한 상태에서 참여한 개발자들이 Community 의 분위기를 해치거나 악영향을 줄 가능성이 있기 때문에 사전에 이에 대한 Guide 를 제시한 셈이다.

리눅스 community 에 참여하는 법

오늘 나는 이 문서의 내용중에서 특히 기본적으로 알고 있어야할 Linux Kernel 의 Versioning 에 관해 요약해보려고 한다.
Linux Kernel 의 버전 관리가 이전에 비해서 좀더 복잡해진 가운데, 릴리즈 주기가 약 3 개월 단위로 짧아진 것은 버전관리 Process 가 그만큼 효율적으로 잘 정립되어 있기 때문이 아닌가 싶다.

참고로, 포스팅을 하고 있는 2014/06/26 일 현재 Linux Kernel 의 최신 Stable 버전은 3.15.1 이며, 2.6.x 버전에서 3.x 버전으로 넘어온 것은 2011 년이다. (이는 Linux Kernel 의 Open 20 주년을 기념하기 위해 버전을 올린 것이라고 한다.)

https://www.kernel.org 에 방문해보면 아래와 같이 몇 가지 종류의 릴리즈 버전들이 존재하는 것을 확인할 수 있다.

위의 버전들이 무엇인가를 이해하려면 아래의 4 가지 종류의 릴리즈 버전의 생성 Process 를 알고 있어야 한다.

• Mainline
• rc (개발버전)
• Stable
• Longterm

Mainline 은 그 유명한 리누스 토발즈가 관리하는 개발 버전의 Main Tree 이다. Git 을 통해 관리되는데 SVN 을 기준으로 말하면 Linux Kernel 코드의 Trunk 라고 할 수 있다.
즉, 모든 Linux Kernel 버전 Tree 의 기준이자 시발점이 된다.

Mainline 은 버전이 3.X 처럼 두 자리가 된다.

리누스 토발즈가 약 2 주 동안 Merge Window 를 열어놓으면 개발자 Community 에서 Accept 되는 모든 변경 사항들이 Mainline 에 Merge 된다. Merge Window 라는 것은 Community 의 개발자들이 Maintainer(코드 관리권한을 부여받은 Community 개발자)를 통해 Linux Kernel Mainline 에 새로운 변경들을 Merge 할 수 있는 기간이 시작되었다는 것을 의미하는 용어이다.
즉, 리누스 토발즈가 Merge Window 를 Open 했다고 공표한 기간에만 Mainline 에 변경들이 Maintainer 를 통해 Merge 될 수 있다. Merge Window 가 닫히면 버그가 아닌 이상 더 이상의 변경들은 Merge 될 수 없다.

리누스 토발즈가 Merge Window 의 종료를 선언하면 그 때의 Linux Kernel 버전이 곧 rc1 이 된다.
만약 Mainline 이 3.12 였다고 가정하고, 그 이전의 최종 Stable 버전이 3.12.20 이었다면, 이번 Merge Window 가 닫힌 직후의 버전은 곧  3.12.21-rc1 이 되는 것이다. (위의 그림은 3.15 에서 3.16 으로 넘어가는 단계라서 3.16-rc2 로 한 것 같다.)
이는 3.12.21 이라는 Stable 버전을 만들기 위한 첫번째 개발 버전이라는 의미라고 보면 되겠다.

Merge Window 가 닫혔다고 곧바로 Stable 버전이 되는 것은 아니고, 6~10 주 동안은 Bug Fix 등과 같은 변경 사항이 Mainline 에 적용될 수 있다. 이러한 변경이 적용되면서 rc2, rc3 와 같이 rc 버전이 올라간다.
보통은 이 기간에 Bug Fix 만이 허용되지만, 예외적으로 기존에 지원하지 않던 H/W 를 지원하는 Driver 를 추가하거나하는 것들은 허용될 수 있다. 이는 기존의 기능들에 해를 끼쳐 퇴화시키는 일(regression)이 없기 때문이다.

보통 r6 ~ r9 정도 되면 해당 개발버전이 어느정도 안정화되었다고 판단하고 3.12.21 이라는 버전으로 Stable 버전을 릴리즈한다.

Stable 버전이 릴리즈되면 이 때부터는 리누스 토발즈가 관리하는 것이 아니라 별도의 Stable Team 에서 관리를 맡게 된다.
Stable Team 은 3.12.21.5 와 같이 4 자리까지 사용하여 3.12.21 Stable 버전에 대한 Update 를 관리해나갈 수 있다. 이렇게 Update 의 대상이 되는 것은 심각한 Bug 이면서 Mainline 에 이미 적용된 것들에만 해당된다.

보통 6 개월 정도 이런 update 릴리즈과정을 거친 후, 그 이후부터는 유지보수가 해당 Kernel 버전을 이용하는 Distributor 의 책임이 된다.

앞에서 리누스 토발즈가 마치 Mainline 에 대한 Merge 들을 모두 관리하는 것처럼 언급했는데, 사실 이는 불가능한 일이다. 엄청나게 많은 변경량을 혼자 확인하고 관리하는 것이 가능하겠는가 ?
이 때문에 Linux Kernel 의 코드 관리는 마치 군대계급처럼 철저하게 Tree 형태의 관리 계급이에 의해 이루어진다.
Network, Memory Management, File System 등 subsystem 관리자(Maintainer)들이 자신의 계급(Level)에 맞는 범위를 관리하게 된다. 그리고, 이러한 관리는 철저하게 신뢰에 바탕을 두고 이루어진다.

Longterm 버전은 말 그대로 이전 버전들 중에서 오랜 기간동안 계속해서 유지관리가 될 버전들을 말한다. longterm 버전을 따로 관리하지 않으면 개발자들이 다양한 stable 버전들에 대해 수정하고자 하는 욕구가 사그라들 것이 분명하다.
그래서, 특정 버전을 longterm 버전으로 지정해두고 이에 대한 관리가 오랜기간 지속될 수 있도록 한 것 같다.

Linux Kernel 의 코드 관리에 있어서 Maintainer 의 역할은 절대적이라고 할 수 있다. 각자 자신이 맡은 영역에 대한 전문가여야하는 것은 물론이고, 코드의 Merge 에 대해서 무한한 열정과 책임을 가진 사람이어야하지 않을까 싶다.

Kernel 개발자들은 이러한 Maintainer 의 존재를 알고 있어야 함은 당연하고, 혹시라도 특정 Kernel 버전의 특정 부분에 대한 질의나 문제점을 찾았을 경우에는 전체 Linux Kernel Mailing List 에 포스팅을 할 것이 아니라 , 어떤 방법으로든 해당 Maintainer 를 찾거나 그 분야의 Mailing List 에 한정하여 포스팅을 하는 것이 좋을 것이다.