제목보고 '1.0.5의 발표 일정에 무슨 일이?' 하실 분들이 대부분이실 겁니다. 네. 문제가 하나 생겼고 함께 의논해보아야 할 것 같습니다.
PAPACHA님이 말씀하시길 1.0.6의 티켓중의 하나인 'UTF8 미지원 database에 대한 field length 전처리 지원 문제' 링크 가 1.0.5 버전의 티켓 링크 을 포함한 여러 티켓들에 하위 종속적입니다. 이곳 QA 게시판이나 버그 게시판에도 종종 보고되는 'null' 경고창 표시 문제나, 일부 트랙백을 받아들일 때 블로그 화면이 깨져나오는 오류등도 전부 저 티켓에 종속적인 문제입니다.
이 문제에 관해서 이해를 돕기 위해 설명을 드리자면, 유니코드가 정식으로 지원되지 않는 MySQL 4.1 이전의 MySQL에서는 UTF-8의 한 글자가 무조건 3바이트를 차지하게 됩니다. (유니코드를 정식으로 지원하는 버전에서는 언어마다 차지하는 용량이 다릅니다. 영문자의 경우 1바이트, 한글이나 일어, 중국어등의 경우 3바이트입니다.) 현재 태터툴즈는 MySQL 4.1 이전의 버전일 경우 3바이트로 통일하여 강제로 집어넣습니다. 그런데 이 경우 가끔 DB의 필드 크기를 넘는 값을 넘겨주는 때가 생깁니다.
길이에 잘라서 넣으면 되지 하시는 분들, 맞습니다. 지금도 잘라서 넣고 있습니다. 
그런데 이게 3바이트 단위다보니 어쩌다가 문자의 중간이 잘리는 경우가 발생합니다. 이럴 경우 해석 불가능한 문자가 마지막에 같이 저장되게 됩니다. 그게 출력될 때 위에서 언급한 오류들이 발생합니다.
그래서 아예 MySQL 3 버전의 DB를 사용하는 유저를 위해 문자열의 종류를 판단하여 정확하게 잘라내는 함수를 만들어, 해당 버전일 경우 '잘 잘라주도록' 만드는 것이 최선입니다. 이를 위한 함수들이 오늘자 trunk와 sandbox에 추가되어 있습니다. 문제는 이 함수들을 이제 char나 varchar와 같은 길이가 지정되어 있는 데이터베이스의 insert 루틴이나 modify루틴에 모두 적용시켜야 한다는 점입니다. 태터툴즈 소스 전반에 걸쳐 광범위하게 존재하죠. 
소스 수정과 추가는 모두 같이 붙잡으면 하루나 이틀이면 하겠지만, 언제나 벌레잡기가 더 오래걸리겠죠? 또한 기존 MySQL 3 사용자들의 DB를 검사하여 올바르게 수정해주는 루틴도 추가되어야 합니다.
이후 DB의 종류에 따른 에러 발생은 없어지겠지만, 아마도 MySQL 3사용자들은 위에서 설명드렸듯 '무조건 3바이트' 때문에 MySQL 4.1 이상의 사용자 분들보다 제목이나 트랙백, 덧글 등에서 약간은 적은 양의 데이터들을 저장할 수 있게 될 것입니다. (현재도 잘라넣기 때문에 사실 지금하고 똑같습니다. 
)
...드디어 결론에 왔습니다.
* 1.0.5 릴리즈의 티켓에 해당되는 리더부분만 우선 수정한 후 이 티켓을 1.0.6으로 가지고 가고 일정대로 1.0.5를 내놓느냐
- 이 경우 일정을 준수하게 됩니다.
- 1.0.6까지의 시간이 1달이 생기기 때문에 MySQL 4.1 미만의 사용자들을 위한 term이 너무 늦다는 의견이 있었습니다.
* 1.0.5 를 우선 내놓고 1.0.6 발표 이전에 MySQL 3 사용자들을 위한 1.0.5.1을 내놓느냐
- 일정을 맞출 수 있습니다.
- 이 경우엔 MySQL3 사용자들이 번거롭습니다.
* 1주일 릴리즈 일정을 연기하고 중간에 베타버전을 한 번 더 내놓느냐
- 환경에 상관없이 에러가 없는 버전을 모든 사용자가 동시에 사용할 수 있습니다.
- 이 경우 일정을 준수하지 못하니 이후에 계획되어 있던 모든 릴리즈 일정이 한 주씩 늦춰지게 될 겁니다.
의 선택의 문제였고, 우선 PAPACHA님과 저는 사용자들의 버그로부터의 불편함이나 여러 버전에 따른 혼동을 막기 위하여 마지막 방법이 가장 낫다는 결론에 도달했습니다.
1주 연기 후 중간에 베타버전을 한 번 더 두는 식으로 beta 3를 5월 4일 (목요일) 오후 3시에, 1.0.5 final을 5월 9일 (화요일) 오후 3시에 발표하는 쪽으로 일정을 수정할까 합니다. 어떻게 생각하시나요?
니들웍스 