Backporting generally starts one of two ways. Sometimes, as a change is being developed for the latest code, the issue is known to apply to older versions and therefore, backporting is known to have value. If it's determined to be worthwhile, the change is backported. But, sometimes older versions are not considered when fixing an issue. Sometimes the backporting process starts when an issue is discovered or reported in an older version and then it's determined that the issue was fixed in a new version, making backporting an economical option as opposed to re-inventing a fix. After the existing change is backported, the development process is like for any change. The changed code is
quality controlled to verify that it exhibits fixed behavior and maintains previous functionality. Then, it is distributed. Multiple modifications are commonly bundled into a single
software update. As for any update, for
closed-source software, backport updates are produced and distributed by the owner of the software, but for
open-source software, anyone can produce and distribute a backported update. A notable process is for the
Linux kernel codebase. Backports are sometimes created by
Linux distributors and later
upstreamed to the core codebase by submitting changes to the maintainer of the changed component. ==Examples==