쟝고는 API의 안정성과 앞으로의 호환성에 대해서 1.0 버전 부터 보장하고 있습니다. 요컨대, 새로 나올 쟝고 버전에서도 기존에 작성한 코드는 문제 없이 돌아갈 것이라는 뜻 입니다. 그렇지만 업그레이드 시에 프로젝트 별 소소한 변경 작업 들은 해줘야 할 수 있습니다. 이에 대해서는 “이전 버전과 호환되지 않는 변경사항” 섹션에서 릴리즈 노트 기존 버전 혹은 업그레이드 대상 버전의 문서를 참조하시기 바랍니다.
\n이 문맥에서, 안정적인 것은 다음을 의미합니다:
\n공개된 모든 API(이 문서에 있든 모든것)들이 이전 버전과 호환되는 별명을 제공하지 않고 이동되거나 이름이 바뀌지 않을 것 입니다.
이 API들에 새로운 기능이 추가된다면, 이 기능들은 이미 존재하는 메소드들의 의미를 바꾸거나 중단시키지 않을 것 입니다. 다시 말하면 “안정적인 것”의 의미는 (어쩔 수 없이) “완벽한 것”이 아닙니다.
만약 어떤 이유로 안정적인 것에 선언된 API가 삭제되야 하거나 대체되야 한다면, 이것은 사용 금지로 선언될 것 입니다 그러나 이것은 앞으로 두번의 릴리스에서 API에 포함될 것 입니다. 사용이 금지된 메소드가 호출될 때 경고들이 발생될 것 입니다.
\nSee Official releases for more details on how Django’s version\nnumbering scheme works, and how features will be deprecated.
\nWe’ll only break backwards compatibility of these APIs if a bug or\nsecurity hole makes it completely unavoidable.
In general, everything covered in the documentation – with the exception of\nanything in the internals area is considered stable.
\n안정성, 하위 호환성 보장에 대한 몇가지 예외가 여기 있다.
\nIf we become aware of a security problem – hopefully by someone following our\nsecurity reporting policy – we’ll do\neverything necessary to fix it. This might mean breaking backwards\ncompatibility; security trumps the compatibility guarantee.
\nCertain APIs are explicitly marked as “internal” in a couple of ways:
\nSome documentation refers to internals and mentions them as such. If the\ndocumentation says that something is internal, we reserve the right to\nchange it.
Functions, methods, and other objects prefixed by a leading underscore\n(_). This is the standard Python way of indicating that something is\nprivate; if any method starts with a single _, it’s an internal API.