API 안정성

쟝고는 API의 안정성과 앞으로의 호환성에 대해서 1.0 버전 부터 보장하고 있습니다. 요컨대, 새로 나올 쟝고 버전에서도 기존에 작성한 코드는 문제 없이 돌아갈 것이라는 뜻 입니다. 그렇지만 업그레이드 시에 프로젝트 별 소소한 변경 작업 들은 해줘야 할 수 있습니다. 이에 대해서는 "이전 버전과 호환되지 않는 변경사항" 섹션에서 릴리즈 노트 기존 버전 혹은 업그레이드 대상 버전의 문서를 참조하시기 바랍니다.

"안정적인 것"의 의미

이 문맥에서, 안정적인 것은 다음을 의미합니다:

• 공개된 모든 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들

In general, everything covered in the documentation -- with the exception of anything in the internals area is considered stable.

예외

안정성, 하위 호환성 보장에 대한 몇가지 예외가 여기 있다.

보안 패치

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 internal

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.