View source for Upstream (software development)

{{short description|Concept in software development}}
{{dicdef|date=May 2023}}
In [[software development]], when software has been [[Fork (software development)|forked]] or uses a chain of [[Library (software)|libraries]]/[[Dependency (software)|dependencies]], '''upstream''' refers to an issue that occurs in software related to the chain. It is the direction that is toward the [[Software engineering|original authors]] or [[Maintenance mode|maintainers]] of [[Computer software|software]]. It is usually used in the context of a version, a [[Software bug|bug]], or a [[Patch (computing)|patch]].

Upstream development allows other distributions to benefit from it when they pick up the future release or merge recent (or all) upstream patches.<ref>{{Cite web |title=Staying Close to Upstream Projects :: Fedora Docs |url=https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/ |access-date=2022-01-18 |website= |publisher=Fedora Project}}</ref> Likewise, the original authors (maintaining upstream) can benefit from contributions that originate from custom distributions, if their users send patches upstream.

The term also pertains to bugs; responsibility for a bug is said to lie upstream when it is not caused through the distribution's [[porting]], non-upstream modification or integration efforts.

== Examples ==
* A patch ''sent upstream'' is offered to the original authors or maintainers of the software. If accepted, the authors or maintainers will include the patch in their software, either immediately or in a future [[Software release life cycle|release]]. If rejected, the person who submitted the patch will have to maintain his or her own [[Software distribution|distribution]] of the author's software.
* Upstream repository or [[source code]] distribution ''version'', which can either be a version-tagged release for which the source code has specifically been packaged, a specific commit, or master (jargon for latest commit). Where custom distributions (such as forks) may have missed out on bugfixes and improvements (maturing of the project tied to the original authors, upstream) as a result of not merging (all) upstream patches. In such cases, the custom distribution may even have been adapted to suit the specific needs and requirements of those using or maintaining it. This is also often seen with dependencies (vendor packages), where the taker just settles with a base version once and tends to stick with it, over time accumulating so many (arbitrary) modifications or non-standard uses in their environment that merging the latest upstream patches into their custom distribution won't be possible without major additional work for patch and feature compatibility, and avoiding duplicate patches of bugs that they resolved by themselves (and in their own way) while upstream also has a patch for it. A lot of custom distribution users would still cherry-pick and merge critical upstream patches (such as [[Vulnerability (computing)|security vulnerability]] related).

== See also ==
{{Portal|Computer programming}}

* [[Backporting]]
* [[Downstream (software development)]]
* [[Fork (software development)]]

== References ==
{{Reflist}}

{{DEFAULTSORT:Upstream (Software Development)}}
[[Category:Computing terminology]]
[[Category:Software project management]]


{{Compu-prog-stub}}