Upgrade: Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
{{short description|Process of replacing a product with a newer version of the same product}}
{{short description|Process of improving something by replacing part of it or adding additional parts}}
{{Other uses}}
{{Other uses}}
{{Redirect|Software Upgrade|the song by Poppy|Poppy.Computer}}
{{Redirect|Software Upgrade|the song by Poppy|Poppy.Computer}}


'''Upgrading''' is the process of replacing
An '''upgrade''' is the result of improving something by replacing part of it or adding additional parts. For example, one can upgrade a [[computer]] by replacing the [[CPU]] with a faster one and by adding more [[RAM]], and afterwards, the computer is an upgrade. Although often used in the context of [[technology]], anything can be upgraded; improved.


a product with a newer version of the same product. In [[computing]] and [[consumer electronics]], an '''upgrade''' is generally a replacement of [[computer hardware|hardware]], [[software]] or [[firmware]] with a newer or better version, in order to bring the system up to date or to improve its characteristics.
Often an update is an upgrade but not always. Update only implies newer; more up-to-date. An update could degrade, or changing to an older version could be an upgrade.


==Computing and consumer electronics==
==Hardware==
Examples of common hardware upgrades include installing additional memory ([[RAM]]), adding larger [[hard disks]], replacing microprocessor cards or [[graphics cards]], and installing new versions of software. Other upgrades are possible as well.
Common [[Computer hardware|hardware]] upgrades include additional [[computer memory|memory]] and [[computer storage|storage]], and replacing the [[CPU]] and [[graphics card]] with faster components.


Common software upgrades include changing the version of an [[operating system]], an [[office suite]], of an anti-virus program, or of various other tools.
Updating hardware involves the risk of compatibility. For example, added RAM may not be compatible with existing RAM in a computer. Other hardware components may not be compatible after either an upgrade or downgrade, due to the non-availability of compatible [[device driver|drivers]] for the hardware with a specific [[operating system]].


Common firmware upgrades include the updating of the [[iPod]] control menus, the [[Xbox 360]] dashboard, or the non-volatile flash memory that contains the [[embedded operating system]] for a [[consumer electronics]] device.
==Software==
In order to upgrade [[software]], a package is often [[download]]ed over the [[Internet]]; sometimes directly by a user and sometimes automatically by a computer. The package may contain only the data needed to modify the existing version; not the entirety of the software. An upgrade may include improved functionality and [[software bug|bug]] fixes such as to eliminate a [[security vulnerability]].


Users can often download software and firmware upgrades from the [[Internet]]. Often the download is a [[patch (computing)|patch]]—it does not contain the new version of the software in its entirety, just the changes that need to be made. Software patches usually aim to improve functionality or solve problems with [[software security vulnerability|security]]. Rushed patches can cause more harm than good and are therefore sometimes regarded{{By whom|date=January 2010}} with skepticism for a short time after release.<ref>{{cite web| title = Windows Vista patch ready for download | author = Lea Rush | date = 2007-08-07 | publisher= IT News Digest | url = http://blogs.techrepublic.com.com/tech-news/?p=976 | access-date = 2008-07-30}}</ref>{{OR|date=April 2024}} Patches are generally free.
Common reasons to create an software upgrade package:<ref>{{cite web|last1=Marini|first1=Paul|title=Best Practices for a Successful Software Upgrade|url=http://blog.spartasystems.com/feed/best-practices-for-a-successful-software-upgrade|publisher=Sparta Systems|access-date=22 June 2015|archive-date=19 September 2015|archive-url=https://web.archive.org/web/20150919202953/http://blog.spartasystems.com/feed/best-practices-for-a-successful-software-upgrade|url-status=dead}}</ref>
* Support industry regulatory requirements
* Access [[emerging technologies]] with new features, and tools
* Meet the demands of changing markets


A software or firmware upgrade can be major or minor and the [[Software versioning#Schemes|release version]] code-number increases accordingly. A major upgrade will change the version number, whereas a minor update will often append a ".01", ".02", ".03", etc. For example, "version 10.03" might designate the third minor upgrade of version 10. In [[proprietary software|commercial software]], the minor upgrades (or updates) are generally free, but the major versions must be purchased.
Upgrading software involves the risk of introducing a bug into the software that might cause it to malfunction. For example, in October 2005, a glitch in a update caused trading on the [[Tokyo Stock Exchange]] to shut down for most of the day.<ref>{{cite web | last = Williams | first = Martyn | title = Software glitch halts Tokyo Stock Exchange | publisher = InfoWorld | date = 2005-11-01 | url = http://www.infoworld.com/article/05/11/01/HNtokyoexchange_1.html?APPLICATION%20PERFORMANCE%20MANAGEMENT | access-date = 2008-07-30}}</ref><ref>{{cite web | last = Associated Press | title = Official: Software glitch, not bomb, shut airport | publisher = NBC News | date = 2006-04-20 | url = https://www.nbcnews.com/id/wbna12411853 | access-date = 2008-07-30}}</ref>


Companies usually make software upgrades for the following reasons: 1.) to support industry regulatory requirements 2.) to access [[emerging technologies]] with new features, and tools 3.) to meet the demands of changing markets 4.) to continue to receive comprehensive product support.<ref>{{cite web|last1=Marini|first1=Paul|title=Best Practices for a Successful Software Upgrade|url=http://blog.spartasystems.com/feed/best-practices-for-a-successful-software-upgrade|publisher=Sparta Systems|access-date=22 June 2015}}</ref>
A software upgrade might result in incompatibility that causes hardware to stop functioning.


==Risks==
A change, considered an upgrade by some, may be considered a downgrade by others. A user may prefer a different version even if the so-called upgrade functions per design. The user might be accustomed to the other version or might miss removed features (see [[iPhone 7#Headphone jack controversy|iPhone jack removal controversy]] or [[OtherOS]]).
Although developers usually produce upgrades to improve a product, there are risks involved—including the possibility that the upgrade will worsen the product.


Upgrades of hardware involve a risk that new hardware will not be compatible with other pieces of hardware in a system. For example, an upgrade of RAM may not be compatible with existing RAM in a computer. Other hardware components may not be compatible after either an upgrade or downgrade, due to the non-availability of compatible [[device driver|drivers]] for the hardware with a specific [[operating system]]. Conversely, there is the same risk of non-compatibility when software is upgraded or downgraded for previously functioning hardware to no longer function.
A change, intended to upgrade, has the risk of [[Brick (electronics)|brick]]ing a device. This can happen for an embedded device in which updates are typically all-or-nothing,{{sfn|the upgrade is a firmware or filesystem image, which isn't usable if it's only partially written}} and which have limited ability to recover from a failed update.<ref name="murphy-compatible">{{cite journal |last=Ben-Yossef |first=Gilad |title=Building Murphy-compatible embedded Linux systems |url=https://www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf |journal=Proceedings of the Linux Symposium |volume=1 |pages=21–36 |access-date=23 June 2016}}</ref> Solutions to this generally involve keeping multiple copies of firmware in device storage, so that one can be upgraded while the other remains intact as a fallback, but there are still holes which can cause this to fail.<ref name="murphy-compatible" /><ref name="swupdate">{{cite web |url=https://sbabic.github.io/swupdate/overview.html |title=Software Management on embedded systems |last=Babic |first=Stefano |access-date=23 June 2016}}</ref><ref name="rauc">{{cite web | url=https://rauc.readthedocs.io/en/latest/ | title=Welcome to the RAUC documentation | access-date=5 May 2020}}</ref> Tools such as [https://mender.io/ Mender.io],<ref>{{Cite web|last=Northern.tech|title=Open source over-the-air software updates for Linux devices|url=https://mender.io/|access-date=2021-08-03|website=mender.io|language=en}}</ref> Sysup,<ref name="murphy-compatible" /> SWUpdate, RAUC,<ref name="rauc" /> and [[OSTree]]<ref name="ostree">{{cite web | url=https://ostree.readthedocs.io/en/latest/manual/introduction/ | title=OSTree Overview | access-date=5 May 2020 | archive-date=15 July 2019 | archive-url=https://web.archive.org/web/20190715083842/https://ostree.readthedocs.io/en/latest/manual/introduction/ | url-status=dead }}</ref> provide solutions that implement upgrades in a safe [[Atomicity (database systems)|atomic]] way, and reduce or eliminate the need to customize bootloaders and other components. Desktop systems are more likely to use something like [[Snapshot (computer storage)|snapshots]] or [[System Restore|restore points]]; these are more efficient as they only require a small fraction of space to store the changes from the old system to the new one, but the lack of a turnkey implementation for embedded systems makes this impractical.
 
Upgrades of software introduce the risk that the new version (or patch) will contain a [[Software bug|bug]], causing the program to malfunction in some way or not to function at all. For example, in October 2005, a glitch in a software upgrade caused trading on the [[Tokyo Stock Exchange]] to shut down for most of the day.<ref>{{cite web | last = Williams | first = Martyn | title = Software glitch halts Tokyo Stock Exchange | publisher = InfoWorld | date = 2005-11-01 | url = http://www.infoworld.com/article/05/11/01/HNtokyoexchange_1.html?APPLICATION%20PERFORMANCE%20MANAGEMENT | access-date = 2008-07-30}}</ref> Similar  have occurred: from important government systems<ref>{{cite web | last = Associated Press | title = Official: Software glitch, not bomb, shut airport | publisher = NBC News | date = 2006-04-20 | url = https://www.nbcnews.com/id/wbna12411853 | access-date = 2008-07-30}}</ref>
to [[freeware]] on the internet.
 
Upgrades can also worsen a product subjectively. A user may prefer an older version even if a newer version functions perfectly as designed. This may happen for a variety of reasons, including the user is already accustomed to the behavior of the old version or because the upgrade removed some features (see [[iPhone 7#Headphone jack controversy|iPhone jack removal controversy]] or  [[OtherOS]]).
 
A further risk of software upgrades is that they can [[Brick (electronics)|brick]] the device being upgraded, such as if power fails while the upgrade is in the middle of being installed. This is an especially big concern for embedded devices, in which upgrades are typically all-or-nothing (the upgrade is a firmware or filesystem image, which isn't usable if it's only partially written), and which have limited ability to recover from a failed upgrade.<ref name="murphy-compatible">{{cite journal |last=Ben-Yossef |first=Gilad |title=Building Murphy-compatible embedded Linux systems |url=https://www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf |journal=Proceedings of the Linux Symposium |volume=1 |pages=21–36 |access-date=23 June 2016}}</ref> Solutions to this generally involve keeping multiple copies of firmware, so that one can be upgraded while the other remains intact as a backup, but there are still holes which can cause this to fail.<ref name="murphy-compatible" /><ref name="swupdate">{{cite web |url=https://sbabic.github.io/swupdate/overview.html |title=Software Management on embedded systems |last=Babic |first=Stefano |access-date=23 June 2016}}</ref><ref name="rauc">{{cite web | url=https://rauc.readthedocs.io/en/latest/ | title=Welcome to the RAUC documentation | access-date=5 May 2020}}</ref> Tools such as [https://mender.io/ Mender.io],<ref>{{Cite web|last=Northern.tech|title=Open source over-the-air software updates for Linux devices|url=https://mender.io/|access-date=2021-08-03|website=mender.io|language=en}}</ref> Sysup,<ref name="murphy-compatible" /> [[SWUpdate]], [[RAUC]],<ref name="rauc" /> and [[OSTree]]<ref name="ostree">{{cite web | url=https://ostree.readthedocs.io/en/latest/manual/introduction/ | title=OSTree Overview | access-date=5 May 2020 }}</ref> provide more complete solutions that implement upgrades in a safe [[Atomicity (database systems)|atomic]] way, and reduce or eliminate the need to customize bootloaders and other components. Desktop systems are more likely to use something like [[Snapshot (computer storage)|snapshots]] or [[System Restore|restore points]]; these are more efficient as they only require a small fraction of space to store the changes from the old system to the new one, but the lack of a turnkey implementation for embedded systems makes this impractical.


== See also ==
== See also ==
{{Wiktionary}}
{{Wiktionary}}
*[[Adaptation kit upgrade]]
*{{Annotated link|Adaptation kit upgrade}}
*[[Advanced Packaging Tool]]
*{{Annotated link|Advanced Packaging Tool}}
*[[Macintosh Processor Upgrade Card]]
*{{Annotated link|Macintosh Processor Upgrade Card}}
*[[Source upgrade]]
*{{Annotated link|Patch (computing)}}
*[[Windows Anytime Upgrade]]
*{{Annotated link|Software update}}
*[[Yellow dog Updater, Modified]]
*{{Annotated link|Source upgrade}}
*[[Patch (computing)]]
*{{Annotated link|Windows Anytime Upgrade}}
*{{Annotated link|Yellow dog Updater, Modified}}


== References ==
== References ==

Latest revision as of 23:21, 7 December 2025

Template:Short description Script error: No such module "other uses". Script error: No such module "redirect hatnote".

An upgrade is the result of improving something by replacing part of it or adding additional parts. For example, one can upgrade a computer by replacing the CPU with a faster one and by adding more RAM, and afterwards, the computer is an upgrade. Although often used in the context of technology, anything can be upgraded; improved.

Often an update is an upgrade but not always. Update only implies newer; more up-to-date. An update could degrade, or changing to an older version could be an upgrade.

Hardware

Common hardware upgrades include additional memory and storage, and replacing the CPU and graphics card with faster components.

Updating hardware involves the risk of compatibility. For example, added RAM may not be compatible with existing RAM in a computer. Other hardware components may not be compatible after either an upgrade or downgrade, due to the non-availability of compatible drivers for the hardware with a specific operating system.

Software

In order to upgrade software, a package is often downloaded over the Internet; sometimes directly by a user and sometimes automatically by a computer. The package may contain only the data needed to modify the existing version; not the entirety of the software. An upgrade may include improved functionality and bug fixes such as to eliminate a security vulnerability.

Common reasons to create an software upgrade package:[1]

  • Support industry regulatory requirements
  • Access emerging technologies with new features, and tools
  • Meet the demands of changing markets

Upgrading software involves the risk of introducing a bug into the software that might cause it to malfunction. For example, in October 2005, a glitch in a update caused trading on the Tokyo Stock Exchange to shut down for most of the day.[2][3]

A software upgrade might result in incompatibility that causes hardware to stop functioning.

A change, considered an upgrade by some, may be considered a downgrade by others. A user may prefer a different version even if the so-called upgrade functions per design. The user might be accustomed to the other version or might miss removed features (see iPhone jack removal controversy or OtherOS).

A change, intended to upgrade, has the risk of bricking a device. This can happen for an embedded device in which updates are typically all-or-nothing,Template:Sfn and which have limited ability to recover from a failed update.[4] Solutions to this generally involve keeping multiple copies of firmware in device storage, so that one can be upgraded while the other remains intact as a fallback, but there are still holes which can cause this to fail.[4][5][6] Tools such as Mender.io,[7] Sysup,[4] SWUpdate, RAUC,[6] and OSTree[8] provide solutions that implement upgrades in a safe atomic way, and reduce or eliminate the need to customize bootloaders and other components. Desktop systems are more likely to use something like snapshots or restore points; these are more efficient as they only require a small fraction of space to store the changes from the old system to the new one, but the lack of a turnkey implementation for embedded systems makes this impractical.

See also

Template:Sister project

References

<templatestyles src="Reflist/styles.css" />

  1. Script error: No such module "citation/CS1".
  2. Script error: No such module "citation/CS1".
  3. Script error: No such module "citation/CS1".
  4. a b c Script error: No such module "Citation/CS1".
  5. Script error: No such module "citation/CS1".
  6. a b Script error: No such module "citation/CS1".
  7. Script error: No such module "citation/CS1".
  8. Script error: No such module "citation/CS1".

Script error: No such module "Check for unknown parameters".