Agno는 8월 30일 20:45:21 UTC에 v3.0.3를 공개하며 지식 관리 도구 모음을 도입했다. 이어 22:40:41 UTC에 v3.0.4를 공개했는데 — 1시간 55분 뒤였다 — 이 패치 릴리스를 통해 도구 모음의 공개 인터페이스를 다시 작성했다.
패치에서 바뀐 것
패치 버전에 들어가서는 안 되는 세 가지가 있었다. 모듈 경로가 이동했지만, 호환성 시임은 남지 않았다. 네 개의 생성자 플래그는 이름이 바뀌었다. 그리고 생성자가 알 수 없는 키워드 인자를 처리하는 방식 때문에, 옛 이름은 거부되지 않는다 — 조용히 무시된다.
조용한 실패가 큰소리 실패보다 더 나쁜 이유
문제가 되는 것은 바로 마지막 부분이다. 플래그 이름 변경이 오류를 발생시키면, 영향을 받는 모든 배포가 시작 단계에서 큰소리로 실패하고 몇 분 안에 누군가 수정한다. 옛 이름이 조용히 버려지면 생성자는 자기 기본값으로 되돌아가며 — 어떤 기능을 비활성화하려고 플래그를 작성한 운영자는 업그레이드 후 그 기능이 켜진 상태로 바뀌는 것을, 오류도 경고도 로그도 없이 보게 된다. 업그레이드는 성공한 것처럼 보인다. 그러나 그때 전달하던 설정은 살아남지 못한다.
안전 수정을 담은 버그 항목
같은 릴리스는 저장된 콘텐츠를 파괴할 수 있는 유일한 도구에 붙어 있던 확인 게이트를 기본값에서 떨어뜨리던 버그도 수정했다. 이는 안전과 관련된 수정이다. 그러나 릴리스 노트에서는 다른 사소한 버그 항목들 사이에 일반적인 버그 항목으로만 적혀 있어, 운영자가 긴급히 업그레이드해야 할 이유라는 점을 드러내지 않는다.
통상적 해석이 틀리는 지점
시맨틱 버전 관리는 널리 하나의 계약으로 읽힌다. 패치 숫자가 올라가면 안전하게 적용해도 된다는 뜻이라는 해석이다. 하지만 여기서 패치 자릿수는 시임 없는 모듈 이동, 이름이 바뀐 네 개의 플래그, 그리고 바뀐 실제 기본값을 모두 감싼다. 이는 깨지는 변경의 정의 그 자체다. 게다가 이 프로젝트는 원칙도 알고 있었다. 같은 날 더 이른 릴리스는 조용히 무시되는 키워드 인자를 삼키는 대신 거부해야 한다고 주장했다. 그 입장은 명시됐지만, 몇 시간 뒤 자기 자신의 이름 변경에는 적용되지 않았다.
업그레이드 방법
3.0.3에서 3.0.4로의 업그레이드를 평범한 버전 상승으로 여기지 말아야 한다. 업그레이드 전에 옛 플래그 이름과 옛 모듈 경로를 grep으로 찾아야 한다. 설치 프로그램도 런타임도 그 의미가 더 이상 없어진 사실을 알려주지 않기 때문이다.