Upstream (software development)

In software development, when software has been forked or uses a chain of libraries/dependencies, upstream refers to an issue that occurs in software related to the chain. It is the direction that is toward the original authors or maintainers of software. It is usually used in the context of a version, a bug, or a patch.

Upstream development allows other distributions to benefit from it when they pick up the future release or merge recent (or all) upstream patches.[1] 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 release. If rejected, the person who submitted the patch will have to maintain his or her own 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 security vulnerability related).

See also

References
  1. "Staying Close to Upstream Projects :: Fedora Docs". Fedora Project. Retrieved 2022-01-18.


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.