Django is committed to API stability and forwards-compatibility. In a nutshell,\nthis means that code you develop against a version of Django will continue to\nwork with future releases. You may need to make minor changes when upgrading\nthe version of Django your project uses: see the “Backwards incompatible\nchanges” section of the release note for the version\nor versions to which you are upgrading.
\nAt the same time as making API stability a very high priority, Django is also\ncommitted to continual improvement, along with aiming for “one way to do it”\n(eventually) in the APIs we provide. This means that when we discover clearly\nsuperior ways to do things, we will deprecate and eventually remove the old\nways. Our aim is to provide a modern, dependable web framework of the highest\nquality that encourages best practices in all projects that use it. By using\nincremental improvements, we try to avoid both stagnation and large breaking\nupgrades.
\n이 문맥에서, 안정적인 것은 다음을 의미합니다.
\n공개된 모든 API(이 문서에 있든 모든것)들이 이전 버전과 호환되는 별명을 제공하지 않고 이동되거나 이름이 바뀌지 않을 것 입니다.
이 API들에 새로운 기능이 추가된다면, 이 기능들은 이미 존재하는 메소드들의 의미를 바꾸거나 중단시키지 않을 것 입니다. 다시 말하면 “안정적인 것”의 의미는 (어쩔 수 없이) “완벽한 것”이 아닙니다.
만약 어떤 이유로 안정적인 것에 선언된 API가 삭제되야 하거나 대체되야 한다면, 이것은 사용 금지로 선언될 것 입니다 그러나 이것은 앞으로 두번의 릴리스에서 API에 포함될 것 입니다. 사용이 금지된 메소드가 호출될 때 경고들이 발생될 것 입니다.
\nOfficial releases에 Django 버전 번호를 붙이는 기준과, 어떻게 기능들이 비활성화 되는지에 대한 자세한 설명이 있습니다.
\nWe’ll only break backwards compatibility of these APIs without a deprecation\nprocess if a bug or security hole makes it completely unavoidable.
일반적으로 모든 것을 문서에서 다루되 내부 영역에 있는 것은 안정적이라고 간주합니다.
\n이러한 안정성과 하위 호환성 보장에 대한 몇 가지 예외가 있습니다.
\n우리가 보안 보고 정책에 따라 보안 문제를 인지하게 되면, 그것을 해결하기 위해 무엇이든 할 것입니다. 이것은 하위 호환성을 깰 수도 있다는 말입니다. 보안이 호환성 보장보다 우선이기 때문입니다.
\n어떤 API들은 다양한 방법으로 “internal”로 표시됩니다.
\n몇몇 문서에서 internal이라고 언급한 경우. 문서에 어떤 것이 internal이라고 되어 있을 경우, 우리는 그것을 변경할 권한이 있습니다.
밑줄(_)로 시작하는 함수, 메서드, 그외 객체. 이것은 Python에서 어떤 것이 비공개(private)임을 표시하는 표준 방식입니다. _로 시작하는 메서드는 내부 API입니다.