Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Upstream (software development)
open-in-new
<h2 id="examples">Examples</h2> <ul><li>A patch <i>sent upstream</i> 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 <a href="/facts/Software_release_life_cycle/z4Q4RElA">release</a>. If rejected, the person who submitted the patch will have to maintain his or her own <a href="/facts/Software_distribution/Q0Qh8qYj">distribution</a> of the author's software.</li> <li>Upstream repository or <a href="/facts/Source_code/o9J6Jv23">source code</a> distribution <i>version</i>, 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 <a href="/facts/Vulnerability_(computing)/jg0Gr71M">security vulnerability</a> related).</li></ul> <h2 id="see-also">See also</h2> <ul> <li>Computer programming portal</li></ul> <ul><li><a href="/facts/Backporting/tyMsA9LN">Backporting</a></li> <li><a href="/facts/Downstream_(software_development)/NQR6mAeY">Downstream (software development)</a></li> <li><a href="/facts/Fork_(software_development)/D6khxhpr">Fork (software development)</a></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>"Staying Close to Upstream Projects :: Fedora Docs". Fedora Project. Retrieved 2022-01-18. <a href="https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/" target="_blank">https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> </ol>