---
title: "Stabilność API"
version: 2.0
locale: pl
source: https://docs.djangoproject.com/pl/2.0/misc/api-stability/
canonical: https://djangodocs.dev/pl/2.0/misc/api-stability/
---
# Stabilność API

Django gwarantuje stabliność i kompatybilność wsteczną API od wersji 1.0. W skrócie, to znaczy, że kod, który pisałeś w jakiejś wersji Django będzie wciąż działał z przyszłymi wydaniami. Możesz musieć wprowadzić małe zmiany podczas upgrade’owania wersji Django, z której korzysta twój projekt: zobacz sekcje „Zmiany niekompatybilne wstecz” [notatek o wydaniach](/pl/2.0/releases/) dla wersji z której lub wersji z których się upgrade’ujesz.

## Co oznacza „stabilny” (ang. stable)

W tym kontekście, stabilny oznacza:

- Wszystkie publiczne API (wszystkie są w tej dokumentacji) nie będą przeniesione ani nie zostaną zmienione ich nazwy bez dodanych wstecznie kompatybilnych aliasów.
- Jeśli do tych API zostaną dodane nowe elementy – co jest całkiem możliwe – nie złamią ani nie zmienią znaczenia istniejących metod. Innymi słowy „stabline” nie (koniecznie) zawsze znaczy „kompletne”.
- Jeśli z jakiegoś powodu API określane jako stabilne musi zostać usunięte lub zmienione, zostanie oznaczone jako dezaprobowane, ale pozostanie w API w co najmniej dwóch kolejnych wydaniach. Przy wywołaniu dezaprobowanej metody wyświetlą się ostrzeżenia.

  Zobacz [Oficjalne wydania](/pl/2.0/internals/release-process/#official-releases) aby poznać więcej szczegółów o tym jak działa schemat numerowania wersji Django i kiedy funkcjonalności będą dezaprobowane.
- Porzucimy kompatybilność wsteczną tego API tylko jeśli wystąpi błąd lub stworzy to nieuniknioną dziurę w bezpieczeństwie

## Stabilne API

W ogólności, wszystko pokryte przez dokumentację – z wyjątkiem czegokolwiek w  [internals area](/pl/2.0/internals/) jest uważane za stabilne.

## Wyjątki

Tutaj znajduje się kilka wyjątków co do stabilności i wstecznej zgodności.

### Poprawki bezpieczeństwa

Jeśli zauważymy problem bezpieczeństwa - w najlepszym przypadku za sprawą kogoś śledzą [security reporting policy](/pl/2.0/internals/security/#reporting-security-issues) – zrobimy wszystko co konieczne by to naprawić. To może znaczyć brak wstecznej kompatybilności; bezpieczeństwo jest ważniejsze od gwarancji kompatybilności.

### API oznaczone jako wewnętrzne

Niektóre API są wprost oznaczone jako „wewnętrzne” na kilka sposobów:

- Czasem dokumentacja odnosi się do elementów i oznacza je jako wewnętrzne. Jeśli dokumentacja mówi, że coś jest wewnętrzne, rezerwujemy prawo do zmiany tego
- Funkcje, metody i inne obiekty poprzedzone prefiksem podkreślenia (`_`). Jest to standard Pythona mówiący, że coś jest prywatne; jeśli każda metoda zaczyna się pojedynczym podkreśleniem \_, to jest to wewnętrzne API.