다양한 소프트웨어 버전 명명 (Software versioning)

세월이 흐르면서 여러 가지 방법의 소프트웨어 버전 명명이 존재했었습니다.

결국 추세는 Symantic Versioning으로 기울었고, 현재는 많은 개발자가 Semantic Versioning을 따르기를 당연 시 하며, 왜 써야 하는지도 이해하고 있습니다.

하지만 의외로 많은 서비스들이 시맨틱 버전을 따르지 않습니다. 왜일까요?

당장 제가 다니고 있는 회사만 보더라도 Semantic Versioning과 다른 방식의 버전 명명법 두 가지를 사용하고 있습니다.

이와 관련하여 예전에 고민했던 내용을 이번 기회에 정리해서 포스트를 올려 봅니다.

Semantic Versioning

Major, Minor 그리고 Patch의 의미를 담고 있는 버전 명명법입니다.

{major}.{minor}.{patch}

Major: 이전 버전과 호환이 안 되는 변경이 있다면 숫자를 올립니다
Minor: 이전 버전과 호환되는 기능 추가가 있다면 숫자를 올립니다.
Patch: 이전 버전의 버그를 수정했다면 숫자를 올립니다.

그리고 시험판(알파 베타 등) 및 추가 메타데이터들은 patch 뒤에 확장으로 제공됩니다.

공개된 라이브러리나 오픈소스라면 필수적인 Versioning 방법입니다.

가장 자주 언급되며 현재까지 매우 많이 알려진 버전 명명법이기 때문에 자세한 설명은 생략하도록 하겠습니다.

이에 대한 자세한 설명은 공식 Spec 문서를 참고해 주세요.

CalVer (날짜 기반 Versioning)

Calendar Versioning — CalVer

CalVer is a versioning convention based on your project's release calendar, instead of arbitrary numbers. Versioning gets better with time. For maintainers, versioning allows us to specify precise dependencies within an ever-expanding ecosystem. For seller

calver.org

여러 프로젝트가 CalVer라는 날짜 기반 버전 관리 체계를 사용합니다.

Ubuntu Linux를 보면 다음과 같은 버전을 가지고 있습니다.

Ubuntu 4.10 (Warty Warthog)
...
Ubuntu 19.04 (Disco Dingo)
Ubuntu 19.10 (Eoan Ermine)
Ubuntu 20.04 LTS (Focal Fossa)

우분투는 버전 명명을 연도 및 월로 사용하고 있습니다.

처음 우분투가 릴리즈 된 게 2004년도 10월이란 걸 버전명만 보고 알 수 있습니다.

이런 버저닝을 통해서 우리는 SemVer와는 다른 이점을 가질 수 있습니다.
예를 들어 우분투는 짝수년 2/4 분기에 발생하는 모든 4번째 릴리즈를 LTS 릴리즈로 지정합니다.
그리고 이런 LTS 버전의 경우 5년 정도의 지원을 해주게 됩니다.

이 말인즉 만약 제가 16.04 LTS 버전을 쓰고 있었다면, 이 버전의 지원 기간이 2021년도 4월까지인걸 패치 명만 보고도 짐작할 수 있기 때문에 이에 따른 액션을 할 수 있습니다.

날짜 번호는 마케팅으로도 사용될 수 있습니다.

Microsoft Office, Windows를 보면 쉽게 알 수 있습니다.
Microsoft Windows 95 -> MS-DOS 7.00 or Windows 4.00
Microsoft Windows 2000 Server - Windows NT 5.0

마케팅을 위해 사용자가 인식하기 쉬운 타이틀을 사용하지만, 실제로 각각의 버전은 전혀 다른 실제 버전을 따로 가지고 있습니다.

NumVersion (숫자 기반 버저닝)

Apple은 NumVersion을 기반으로 한 공식 버전 번호 구조로 되어 있습니다.

한자리 혹은 두 자리의 메이저 버전, 한자리의 마이너 버전, 한자리의 버그 버전이 있고 스테이지 단계에서 추가 suffix를 사용하고 릴리즈 할 때 추가 suffix를 제거합니다.

1.0 버전에다 다음 버전을 개발한다면, 1.1.0a0 이런 식으로 suffix를 가지고 있습니다. 그 후 1.1.0f0와 같이 개발 버전이 올라가고, 릴리즈 시에는 스테이지 단계의 suffix를 제거하여 1.1이 됩니다.

이는 최종단계에서 깔끔한 버전을 사용하게 되는 장점이 있습니다.

소프트웨어 개발 시 패치 별로 제공하려는 기능에 대한 집중이 가능하기도 합니다.

TeX

스탠퍼드대학교의 도널드 커누스(Donald Knuth) 교수가 만든 조판 언어, 시스템입니다.

markdown에서 수식 입력으로 사용하는 LaTeX가 TeX를 기반으로 만들어졌습니다.

The Art of Computer Programming 책을 집필하는데 그 당시 제공되던 출판 프로그램의 수식 표시가 마음에 들지 않아 만들었다고 합니다.

논외지만 저 책... 8년인가 전쯤에 멋모르고 읽다가 포기했었는데 언젠가 다시 도전해야겠네요.

아무튼 다시 돌아와서, TeX의 메이저 버전은 3이고 현재 최신 버전은 3.14159265입니다.

보이는 숫자처럼 어마어마한 양의 패치를 한 건 아니고, 패치가 될 때마다 원주율을 이용해 숫자를 하나씩 추가했습니다.

총 8번의 패치가 있었던 셈입니다.

도날드 커누스는 패치 번호를 원주율로 설정하고, 이 시점에서 나머지 모든 버그는 기능으로 선언되며 TeX의 출력은 영원토록 동일하게 유지되었습니다.

Java

Java는 복잡한 버전 명명법을 가지고 있습니다.

우선 마케팅 버전과 실제 버전, 즉 두 가지의 버전이 있습니다.

마케팅 버전은 또다시 아래와 같이 나뉩니다.

Standard Edition (SE)
Micro Edition (ME)
Enterprise Edition (EE)

Java의 Android 또한 Java SE와 크게 다릅니다.

실제 버전은 아래와 같이 표현됩니다.

1.8.0_101-b13

이것은 JDK 1.8.0, Update 101, Build # 13을 말합니다. Oracle은 릴리스 노트에서 다음과 같이 언급합니다.

Java™ SE Development Kit 8, Update 101 (JDK 8u101)

Java 8은 Java 1.8과 같으며 Java 8은 단지 마케팅 이름일 뿐입니다.

개발을 처음 배울 때 Java 버전이 너무 헷갈리게 되어있고 SE를 깔아야 할지 EE를 깔아야 할지 고민했던 기억이 나네요.

Eclipse

이클립스 또한 버전 명명이 특이하게 바뀐 케이스입니다.

코드네임을 공개적인 버전으로 썼는데 위성 이름을 쓰다가 갈릴레오 갈릴레이 이름을 따오고(Callisto, Europa, Galileo),

알파벳 네이밍을 하더니
Helios(2010년), Indigo(2011년), Juno(2012년), Kepler(2013년), Luna(2014년), Mars(2015년),

2018년 드디어 연도-월 버저닝으로 변경하게 됩니다.

이클립스를 써보신 분들은 공감하실 듯합니다, 알파벳 네이밍에서는 뭐가 최신 버전인지 매우 헷갈렸으나 연도-월 버저닝을 쓰고부터 인식하기가 좋아졌습니다.

BLAG Linux and GNU

리눅스의 한 종류 같습니다만 처음 들어봅니다. 각설하고 BLAG Linux는 엄청 큰 버전 번호를 제공합니다.

메이저 릴리즈에는 50000, 60000의 숫자를 사용하며, 마이너 릴리즈는 숫자를 1씩 증가시킵니다. (50001, 50002)

2014년에는 200000버전이 릴리즈 되었다고 합니다.

특이하게 알파 및 베타 릴리즈는 주 릴리즈보다 약간 적은 번호를 사용합니다.
20000의 알파 1 - 19999.00071
30000의 베타 2 - 29999.50000

숫자가 마치 워해머스럽기도 하고, 뭐랄까 따라 하고 싶진 않지만 상남자 느낌이...

멋있네요.

Windows 10

윈도우는 마케팅용으로 Windows 10이라는 버전 명을 사용하지만, 또한 실제 빌드 버전도 가지고 있습니다.

버전 Windows 10 Pro
버전 1511
OS 빌드 10586.104

1511은 15년 11월에 대규모 업데이트를 했다는 뜻입니다.

Venngage

Venngage는 수많은 포스터, 인포그래픽 템플릿을 제공하는 온라인 에디터입니다.

Venngage
Venngage LinkedIn Top Startups 2019에 선정되다

Free Infographic Maker - Venngage

Join over 1 million people creating their own professional graphics with our easy to use infographic maker. Sign up for free and choose from 1000+ infographic templates.

venngage.com

2019년 8월 - LinkedIn Top Startups 2019에 선정되다

2019년 8월 - LinkedIn Top Startups 2019에 선정되다2019년 8월 링크드인 탑 스타트업에 선정되다 LinkedIn Top Startups 2019: The 25 hottest Canadian companies to work for now 캐나다의 핫한 스타트업 25에 선정되었습니다. 해당 기사에만 언급될 뿐만 아니라 게임 업적처럼 회사 메인 배너에 메달과 텍스트를 추가해주네요. 그저 간지. LinkedIn - Venngage L

journey.sonim1.com

소소하게 여행 블로그에 올리며 자축도 했었는데요 흠흠 아무튼

제가 다니고 있는 회사에서 사용하는 버전 명명법입니다.

작년 초까지는 메인 애플리케이션에 대하여 SemVer를 따랐었습니다.

이 당시 직원들이 늘어나는 시기와 맞물려 Agile 프로세스를 Spotify의 Squad 방식으로 바꾸었고, 그에 따라 릴리즈 주기가 1주일로 변경되었습니다.

매주 마이너 버전이 1씩 올라가니 금세 세 자릿수를 돌파하려고 했더랬죠, 결국 2.98까지 올라온 버전 명을 보고 엔지니어들 간의 마찰이 생겨났습니다.
3으로 올려야 한다. 2.100으로 세 자릿수로 가야 한다. 아니면 다른 버전 체계를 사용해야 한다 등등 말이죠.

결국 많은 상의 끝에 CalVer를 수정한 버전 명을 사용하게 되었습니다.

{year}.{weeknumber}.{patch}

week number는 몇 번째 주인지를 의미합니다. 1년에 총 52까지 증가할 수 있습니다.

현재는 20.14.0 릴리즈를 앞두고 있습니다.

배포는 Github flow를 약간 개선해서 사용하고 있습니다.

이 또한 비슷한 맥락인데 10년 전에 정의되어 있는 git flow를 많은 곳에서 따르고 있습니다. 공식 문서에서도 그에 따라 최근에 업데이트되었고 github flow를 따르기를 권장하고 있습니다.
만약 Git Flow를 사용하고 있다면 Github Flow로 변경해 보는 것 또한 권장합니다.

A successful Git branching model » nvie.com

A successful Git branching model

In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.

nvie.com

Understanding the GitHub flow · GitHub Guides

Create a branch When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. When y

guides.github.com

마치며

새로운 개발자나 인턴이 들어올 때 왜 SemVer를 쓰지 않는지 궁금해하는 경우가 있어서 정리도 할 겸 기억을 돌이켜 글을 작성했습니다.

현재도 사실 많은 분들이 For this system to work, you first need to declare a public API 이 부분을 간과하고 SemVer를 사용하고 있습니다. 다시 자신의 서비스를 돌아보고 적합한 방식으로 개선한다면 이 부분을 통해서 생산성을 향상할 수 있을 것입니다.