Editing Backporting (section)

==Overview==
The simplest and probably most common situation of backporting is a fixed security hole in a newer version of a piece of software. Consider this simplified example:

* Software v2.0 had a [[security vulnerability]] that is fixed by changing the text 'is_unsecured' to 'is_secured'.
* The same security hole exists in Software v1.0, from which the [[codebase]] for the newer version is derived, but there the text may read 'is_notsecure'.

By taking the modification that fixes Software v2.0 and changing it so that it applies to Software v1.0, one has effectively backported the fix.<ref name="redhat-backporting">{{cite web | url = https://access.redhat.com/security/updates/backporting/ | title = Backporting Security Fixes | publisher = [[Red Hat]] | access-date = 2020-05-11 | archive-date = 2020-05-12 | archive-url = https://web.archive.org/web/20200512171443/https://access.redhat.com/security/updates/backporting/ | url-status = live }}</ref>

In real-life situations, the modifications that a single aspect of the software has undergone may be simple (only a few lines of [[Source code|code]] have changed) up to heavy and massive (many modifications spread across multiple [[Computer file|files]] of the code). In the latter case, backporting may become tedious and inefficient and should only be undertaken if the older version of the software is really needed in favour of the newer (if, for example, the newer version still suffers [[Robustness (computer science)|stability]] problems that prevent its use in mission-critical situations).<ref name="fedora-upstream">{{cite web | url = https://fedoraproject.org/wiki/Staying_close_to_upstream_projects | title = Staying close to upstream projects | author = Rahul Sundaram | date = 2016-01-14 | publisher = [[Fedora Project]] | access-date = 2020-05-11 | archive-date = 2011-08-05 | archive-url = https://web.archive.org/web/20110805082914/http://fedoraproject.org/wiki/Staying_close_to_upstream_projects | url-status = live }}</ref>