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