태그 보관물: version

API 번호가 없는 Android 버전은 누구인가?

Android, Software, ,

Android SDK Manager를 보면, API 10은 2.3.3이다. 그리고 그 다음 버전은 API 11은 3.0 허니컴이다. 하지만, 단말 중에 보면 Android 2.3.4 ~ 2.3.7 사이의 버전을 가진 단말들이 있다. 대표적으로는 꽤 오랫동안 OS 업데이트를 해준 갤럭시 S 인데, SKT용 갤럭시 S의 경우 2.3.6이 최신 버전이다.

device-2014-02-01-234438

 

얘네들은 뭘까? 몇개 되지 않으니 하나씩 찾아보자. 먼저 2.3.4는 API 10의 MR1이다. 안드로이드 개발자 사이트의 What is API Level?을 보면 2.3.4는 API 10에 포함되는 표로 나와있다. 

2.3.5 ~ 2.3.7은 위키피디아의 안드로이드 버전 역사를 보면 유추해 볼 수 있다. 구글이 구글 사이트에 언급하지 않았거나 API 번호를 주지 않은 것들은 대체적으로 특정단말에서 발생하지만 치명적인 문제(네트워크나 구글 주요 서비스)를 수정한 것으로 보인다. 대신에 API 번호를 줄만큼 API가 변경되지 않았다고 판단한 것 같다. 참고로, 진저브레드(2.3.x) 버전에서만 이와같은 마이너 버전이 나와서 사람을 혼란스럽게 한 것은 아니다. 특히 허니컴(3.x)에서는 3.2.1 ~ 3.2.6까지 6번이나 마이너한 버전이 있다.

그럼 세번째 소숫점 자리는 마이너한 수정이라고만 생각하면 될까? 그럼 API 16인 4.1.2나 API 17인 4.2.2는 또 뭐지??!

내 생각은 이렇다. 모두 알다 시피 안드로이드는 오픈소스다. 소스가 공개되어 있고, 이를 기반으로 버전을 만들 수 있다. 많은 제조사들에서도 자사 단말을 위해 이를 수정/배포한다. 이중에서 레퍼런스 폰을 만드는 회사(삼성, HTC, LG)나 자사의 자회사(모토롤라)의 수정은 메인에 포함시켜야 했을거다. 2.3.5~2.3.7의 변경 내역을 보면 수정내용이 작기도 하지만 이 것은 버전을 그렇게 관리했기 때문일 것이고, 4.1.2나 4.2.2에도 API 버전이 부여된 것으로 보면 구글이 스스로 수정을 가한 경우에만 API 버전을 주는게 아닐까 추측해본다.  주도권은 자기들이 가지고 있겠다는 속내가 보인다.

구글은 오픈소스이므로 누구나 참조할 수 있지만, 실제 제조사들은 단말을 내보내기 전에 구글의 승인을 받고 있다. 그리고 구글의 승인을 받지 않은 커스텀 버전, 대표적으로 사이아노젠 모드같은 경우 처음에는 구글 마켓을 그대로 넣어서 바이너리를 배포했는데 구글의 지적(?)을 받아 최근에 발행되는 바이너리에는 구글 마켓 대신에 자체 마켓이 포함되어 있다.

소프트웨어 버전 붙이기

Android, Software

참조 : http://en.wikipedia.org/wiki/Software_release_life_cycle

소프트웨어 릴리즈 라이프 사이클에 대한 좋은 글은 많다. 이미 체계도 많이 잡혀져 있다. 다만, 개인적으로 약식 버전을 사용하는데 이에 대한 정리를 해본다. 참조에도 나온 소프트웨어 릴리즈 라이프 사이클에서 나는 아래와 같은 단계정도만 사용한다.

  • Alpha > Beta > Release Candidate > Release

이중에 Release Candidate까지는 개발 단계이고, Release는 공개된 단계이다. 이를 안드로이드 어플리케이션에서 버전으로 사용할 때는 a,b,c를 꼬리표로 붙인다.  그 예는 다음과 같다.

2.00.11 버전을 내놓고 싶다면,

  • Alpha 버전 : 개발 팀 내부 버전
    예) 2.00.11a
  • Beta 버전 : 사내 검증 받는 버전
    예) 2.00.11b
  • Release Candidate 버전 : 사내 검증이 완료된 버전
    예) 2.00.11c
  • Release 버전 : 사용자에게 공개된 버전
    예) 2.00.11

그리고, 개발 팀 내부 버전이나 사내 검증에서 수정사항이 생겨서 버전을 변경해야 한다면 다음과 같이한다. 주로 사내 검증을 받는 경우에 작은 업데이트가 많이 발생하는데,

2.00.11b > 2.00.11b2 > 2.00.11b3 ...

나 같은 경우에는 서비스 어플리케이션을 만들기 때문에 Release가  O/S나 컴파일러 수준으로 부담이 되지 않는다. 그리고 어플리케이션이 실행되기 전에 업데이트 체크도 진행하고 있다. 그래서 Release 버전을 한 단계로하고, 문제가 생기면 내부적 검증을 통해 추가적으로 Release하는 방식으로 관리한다.

애플과 같은 경우 iOS를 내놓을 경우에는 GA나 GM(?)같은 release 단계에서도 버전을 따로 붙이면서 테스트를 계속 하는데, 개인적으로 방법론이란 관련자들과 혼란과 불편을 줄이는 것에 목적이 있는 것이지 따르는 그 자체에 의미가 있는 것이라고 생각하지 않기 때문에 하고 있는 프로젝트에 따라 맞체 커스터마이징할 수 있다고 생각한다. 다만, 괜히 같은 의미를 좀더 멋지다는 이유로 이름을 바꾼다거나 하여 같은 방법론을 쓰는 사람들끼리 혼란을 일으킬 필요는 없겠다.

내게 그런 경험이 있는데 전에 내가 스레드-풀 디자인 패턴이나 워커 스레드 패턴등에서 사용되는 worker라는 단어를 miner같은 것으로 임의대로 변경한 경우가 있었는데, 기능은 같고 개인적인 취향으로 이름을 바꾼 것이라 혼란을 일으켰던 적이 있었다.