In der Softwareentwicklung bezeichnet „Upstream“ ein Problem in Software, die durch Forking oder die Verwendung einer Kette von Bibliotheken / Abhängigkeiten entstanden ist . Es verweist auf die ursprünglichen Autoren oder Betreuer der Software und wird üblicherweise im Zusammenhang mit einer Version, einem Fehler oder einem Patch verwendet .

Die Weiterentwicklung im Upstream-Projekt ermöglicht es anderen Distributionen, davon zu profitieren, wenn sie zukünftige Versionen übernehmen oder aktuelle (oder alle) Upstream-Patches integrieren. [ 1 ] Ebenso können die ursprünglichen Autoren (die das Upstream-Projekt pflegen) von Beiträgen profitieren, die aus benutzerdefinierten Distributionen stammen, wenn deren Benutzer Patches an das Upstream-Projekt senden.

Der Begriff bezieht sich auch auf Bugs; die Verantwortung für einen Bug liegt angeblich beim Upstream-Entwickler, wenn er nicht durch die Portierung der Distribution , durch nicht-Upstream-Modifikationen oder durch Integrationsbemühungen verursacht wurde.

Beispiele

  • Ein an die Entwickler gesendeter Patch wird den ursprünglichen Autoren oder Entwicklern der Software angeboten. Wird er angenommen, integrieren die Autoren oder Entwickler den Patch in ihre Software, entweder sofort oder in einer späteren Version . Wird er abgelehnt, muss der Einreicher des Patches seine eigene Distribution der Software pflegen .
  • Die Version des Upstream-Repositorys oder der Quellcodeverteilung kann entweder eine Versionsnummer, für die der Quellcode speziell verpackt wurde, ein bestimmter Commit oder der Master-Branch (Fachbegriff für den neuesten Commit) sein. Benutzerdefinierte Distributionen (wie Forks) haben möglicherweise Bugfixes und Verbesserungen verpasst (die Weiterentwicklung des Projekts ist eng mit den ursprünglichen Autoren, dem Upstream-Repository, verbunden), da sie nicht alle Upstream-Patches übernommen haben. In solchen Fällen wurde die benutzerdefinierte Distribution möglicherweise sogar an die spezifischen Bedürfnisse und Anforderungen der Nutzer oder Wartungsteams angepasst. Dies ist häufig auch bei Abhängigkeiten (Anbieterpaketen) zu beobachten: Der Nutzer legt sich einmalig auf eine Basisversion fest und bleibt dabei. Im Laufe der Zeit sammeln sich so viele (willkürliche) Modifikationen oder nicht standardmäßige Verwendungen in seiner Umgebung an, dass die Übernahme der neuesten Upstream-Patches in die benutzerdefinierte Distribution ohne erheblichen zusätzlichen Aufwand für Patch- und Funktionskompatibilität nicht möglich ist. Außerdem müssen doppelte Patches für Fehler vermieden werden, die der Nutzer selbst (und auf seine eigene Weise) behoben hat, obwohl es im Upstream-Repository bereits einen Patch dafür gibt. Viele Nutzer von benutzerdefinierten Distributionen würden immer noch gezielt kritische Upstream-Patches (z. B. solche im Zusammenhang mit Sicherheitslücken ) auswählen und integrieren.

Siehe auch

Referenzen