Latest ads
-
Gemini AI PRO 18 months Offer- Hawaka
- Updated:
-
koko account
- DasunEranga
- Updated:
-
koko account
- DasunEranga
- Updated:
IE7 RC-1 Released
- Thread starter Anusha
- Start date
Software versioning schemes
A variety of version numbering schemes have been created to keep track of different versions of a piece of software. The ubiquity of computers has also led to these schemes being used in contexts outside computing.
Numeric
The most common software versioning scheme is a scheme in which different major releases of the software each receive a unique numerical identifier. This is typically expressed as three numbers, separated by periods, such as version 2.4.13. One very commonly followed structure for these numbers is:
major.minor[.revision[.build]]
or
major.minor[.maintenance[.build]]
In most commercial software, the first released version of a software product has version 1.0. Numbers below 1 mean alpha or beta versions, i.e., versions for testing purposes or internal use, or versions that aren't stable enough for general or practical deployment. In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed. A typical product might use the numbers 0.9 (for beta software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Developers may at times jump (for example) from version 5.0 to 5.5 to indicate that significant features have been added, but not enough to warrant incrementing the major version number. There is sometimes a fourth, unpublished number which denotes the software build (as used by Microsoft). Some companies also include the build date. Version numbers may also include letters and other characters, such as Lotus 1-2-3 Release 1a. A different approach is to use the major and minor numbers, along with an alphanumeric string denoting the release type, i.e. 'alpha', 'beta' or 'release candidate'. A release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 == 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more fixes) == 1.0rc1 (which, if it's stable enough) == 1.0. If 1.0rc1 turns out to have bugs which must be fixed, it turns into 1.0rc2, and so on. The important characteristic of this approach is that the first version of a given level (beta, RC, production) must be identical to the last version of the release below it: you cannot make any changes at all from the last beta to the first RC, or from the last RC to production. If you do, you must roll out another release at that lower level. The purpose of this, is to permit users (or potential adopters) to evaluate how much real-world testing a given build of code has actually undergone. If changes are made between, say, 1.3rc4 and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all. This approach commonly permits the third level of numbering ("change"), but does not apply this level of rigor to changes in that number: 1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4b1, etc.
Date
The Wine project used a date versioning scheme, which uses the year followed by the month followed by the day of the release; for example, "Wine 20040505". Wine is now on a "standard" release track; the most current version as of 8/2006 is 0.9.19.
Year of release
Other examples, identifying versions by year (Adobe Illustrator 88, WordPerfect Office 2003)
Alphanumeric codes
* Macromedia Flash MX
* Adobe Photoshop CS2
Roman numerals
* Apple's Mac OS X, representing version 10
TeX
TeX has an idiosyncratic version numbering system. Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches π. The current version is 3.141592. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. TeX developer Donald Knuth has stated that the "absolutely final change (to be made after my death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.
Apple
Apple has a formalised version number structure based around the NumVersion struct, which specifies a one- or two-digit major version, a one-digit minor version, a one-digit 'bug' (ie revision) version, a stage indicator (drawn from the set development/prealpha, alpha, beta and final/release), and a one-byte (ie having values in the range 0-255) prerelease version, which is only used at stages prior to final. In writing these version numbers as strings, the convention is to omit any parts after the minor version whose value are zero (with 'final' being considered the zero stage), thus writing 1.0.2b12, 1.0.2 (rather than 1.0.2f0), and 1.1 (rather than 1.1.0f0).
Other schemes
Some software producers use different schemes to denote releases of their software. For example, the Microsoft Windows operating system was first labelled with standard numerical version numbers (Windows 1.0 through Windows 3.11), then by years (Windows 95, Windows 98, Windows 2000), and also by alphanumeric codes (Windows Me, Windows XP). The Debian project uses a major/minor versioning scheme for releases of its operating system, but uses code names from the movie Toy Story during development to refer to stable, unstable and testing releases. The Ubuntu GNU/Linux distribution uses the two digit year number followed by the month (4.10, 5.04, 5.10, and 6.06).
Internal version numbers
Software may have an "internal" version number which differs from the version number shown in the product name (and which typically follows version numbering rules more consistently). J2SE 5.0, for example, has the internal version number of 1.5.0, and versions of Windows from 95 on have continued the standard numerical versions internally: Windows 95 is Windows 4.0, 98 is 4.10, 2000 is 5.0, XP is 5.1, 2003 is 5.2, and Vista is 6.0.
Pre-release versions
In conjunction with the various versioning schemes listed above, a system for denoting pre-release versions is generally used. Programs that are in a very early stage of development are often called "alpha" software, after the first letter in the Greek alphabet. After they mature but are not yet ready for release, they may be called "beta" software, after the second letter in the Greek alphabet. Alpha- and beta-version software is often given numerical versions less than 1 (such as 0.9), to suggest their approach toward a public "1.0" release. However, if the pre-release version is for an existing software package (e.g. version 2.5), then an "a" or "alpha" may be appended to the version number. So the alpha version of the 2.5 release might be identified as 2.5a or 2.5.a. Software packages which are soon to be released as a particular version may carry that version tag followed by "rc-#", indicating the number of the release candidate. When the version is actually released, the "rc" tag disappears.
Modifications to the numeric system
Odd-numbered versions for development releases
Up until the 2.6.x series, Linux used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases. For example, Linux 2.3 was a development family of the second major design of the Linux kernel, and Linux 2.4 was the stable release family that Linux 2.3 matured into. After the minor version number in the Linux kernel is the release number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Even further, a trivial version number was added to 2.6.8, making 2.6.8.1 which denoted a very minor change. This fourth number has been made standard since 2.6.11.1.
Apple Computer
Apple had their own twist on this habit during the era of the classic MacOS: although there were minor releases, they rarely went beyond 1, and when they did, they twice jumped straight to 5, suggesting a change of magnitude intermediate between a major and minor release (thus, 8.5 really means 'eight and a half', and 8.6 is 'eight and a half point one'). The complete sequence of versions (neglecting revision releases) is 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (skipping 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.2, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2. OS X has bucked this trend, having gone more conventionally from 10.0 to 10.4, one minor release at a time.
Political significance of version numbers
Version 1.0 as a milestone
Commercial software developers often start at version 1 for the first release of a program and increment the major version number with each rewrite, meaning that a program can reach version 3 within a few months of development, before it's even considered stable or reliable. In contrast to this, the Free Software community tends to use version 1.0 as a major milestone, indicating that the software is "complete", that it has all major features, and is considered reliable enough for general release. In this scheme, the version number slowly approaches 1.0 as more and more bugs are fixed in preparation for the 1.0 release. For example, Firefox released version 0.9, 0.95, and 0.995 as they prepared a "finished" version that would be called Firefox 1.0 The developers of MAME do not intend to release a version 1.0 of their emulator program. The argument is that it will never be truly "finished" because there will always be more arcade games. Version 0.99 was simply followed by version 0.100, even though 0.100 is a smaller decimal number than 0.99.
To describe program history
Winamp released an entirely different architecture for version 3 of the program. Due to lack of backwards compatibility with plugins and other resources from the major version 2, a new version was issued that was compatible with both version 2 and 3. The new version was set to 5 (2+3), jumping version 4.
Keeping up with competitors
There's a common habit in the commercial software industry (usually, though not always, spurned by non-commercial programmers) to make major jumps in numeric major or minor version numbers for reasons which do not seem (to many members of the program's audience) to merit them: "marketing" version numbers. This can be seen in several Microsoft products, as well as Sun Solaris and Java Virtual Machine numbering, SCO Unix version numbers, and Corel Word Perfect, as well as the filePro DB/RAD programming package, which went from 2.0 to 3.0 to 4.0 to 4.1 to 4.5 to 4.8 to 5.0, and is about to go to 5.6, with no intervening release. A slightly different version can be seen in AOL's PC client software, which tends to have only major releases (5.0, 6.0, 7.0, etc...). Also Microsoft Access jumped from version 2.0 to version 7.0, to match the version number of Microsoft Word.
Sun's Java has had the versions:
* JDK 1.0.3
* JDK 1.1.2 through 1.1.8
* J2SE 1.2.0 through 1.4.2
* J2SE 5.0
Significance in software engineering
Version numbers are used in practical terms by the consumer, or client, by being able to compare their copy of the software product against another copy, such as the newest version released by the developer. For the programmer team or company, versioning is often used on a file-by-file basis, where individual parts or sectors of the software code are compared and contrasted with newer or older revisions, often in a collaborative Concurrent Versions System. There is no absolute and definite software version schema; it can often vary from software genre to genre, and is very commonly based on the programmer's personal preference.
Version numbers for files and documents
Some computer file systems, such as the OpenVMS Filesystem, also keep versions for files.
Versioning amongst documents is relatively similar to the routine used with computers and software engineering, where with each small change in the structure, contents, or conditions, the version number is incremented by 1, or a smaller or larger value, again depending on the personal preference of the author and the size or importance of changes made.
Mathematical properties of version numbers
Version numbers very quickly evolve from simple integers (1,2,...) to rational numbers (2.08,2.09,2.10) and then to non-numeric "numbers" such as 4:3.4.3-2. These complex version numbers are therefore better treated as character strings. Operating systems that include package management facilities (such as all non-trivial Linux or BSD distributions) will use a distribution-specific algorithm for comparing version numbers of different software packages. For example, the ordering algorithms of the Red Hat and derived distributions and those of the Debian-like distributions differ.
An ideal ordering algorithm should define a total order on strings. In other words, given two version strings u and v, either u and v should be identical, or u should come before or after v. More formally, if the version comparison algorithm is modeled as a function f(u,v) which returns -1, 0 or 1, the following two properties should hold:
* (A) For all u,v and w, if f(u,v) = -1 and f(v,w) = -1 then f(u,w) = -1 (transitivity),
* (B) For all u and v, if f(u,v) = f(v,u) then u and v should be equal strings (antisymmetry).
Note that (B) also implies reflexivity. If these two conditions do not hold, then we have one of the two situations:
* (I) There is a sequence of version numbers v1,...,vk such that v1<v2<...<vk and vk<v1. In other words, we have a circularity in the version numbering scheme. Version numbers are supposed to reflect software evolution and circularities can wreak havoc with package management systems.
* (II) There exist two different strings u and v such that u and v are equivalent as version numbers.
For instance, in Debian, leading zeroes are ignored in chunks, so that 5.0005 and 5.5 are considered as equal, and 5.5<5.0006. This can confuse users ; string-matching tools may fail to find a given version number ; and this can cause subtle bugs in package management if the programmers use string-indexed data structures such as version-number indexed hash tables.
Note that the ordering of version numbers needs neither be well-founded nor non-Archimedean. The former condition would forbid infinite descending sequences of version numbers. As we live in a finite world, this has no consequence, and in practice, the empty string is usually the minimum of the ordering. The latter would mean that there is always a finite number of versions between two given version numbers. If version strings are unlimited in length, this would mean that it is always possible to insert a new version between two existing versions, which is a desirable feature. It is common for each component of a version number to be treated individually, so that 1.9 need not be followed by 2.0, but by 1.10; it is, as noted above, not safe to assume that mathematical operations can safely be applied to a given version number merely because its representation appears to be that of a real number.
A variety of version numbering schemes have been created to keep track of different versions of a piece of software. The ubiquity of computers has also led to these schemes being used in contexts outside computing.
Numeric
The most common software versioning scheme is a scheme in which different major releases of the software each receive a unique numerical identifier. This is typically expressed as three numbers, separated by periods, such as version 2.4.13. One very commonly followed structure for these numbers is:
major.minor[.revision[.build]]
or
major.minor[.maintenance[.build]]
In most commercial software, the first released version of a software product has version 1.0. Numbers below 1 mean alpha or beta versions, i.e., versions for testing purposes or internal use, or versions that aren't stable enough for general or practical deployment. In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed. A typical product might use the numbers 0.9 (for beta software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Developers may at times jump (for example) from version 5.0 to 5.5 to indicate that significant features have been added, but not enough to warrant incrementing the major version number. There is sometimes a fourth, unpublished number which denotes the software build (as used by Microsoft). Some companies also include the build date. Version numbers may also include letters and other characters, such as Lotus 1-2-3 Release 1a. A different approach is to use the major and minor numbers, along with an alphanumeric string denoting the release type, i.e. 'alpha', 'beta' or 'release candidate'. A release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 == 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more fixes) == 1.0rc1 (which, if it's stable enough) == 1.0. If 1.0rc1 turns out to have bugs which must be fixed, it turns into 1.0rc2, and so on. The important characteristic of this approach is that the first version of a given level (beta, RC, production) must be identical to the last version of the release below it: you cannot make any changes at all from the last beta to the first RC, or from the last RC to production. If you do, you must roll out another release at that lower level. The purpose of this, is to permit users (or potential adopters) to evaluate how much real-world testing a given build of code has actually undergone. If changes are made between, say, 1.3rc4 and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all. This approach commonly permits the third level of numbering ("change"), but does not apply this level of rigor to changes in that number: 1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4b1, etc.
Date
The Wine project used a date versioning scheme, which uses the year followed by the month followed by the day of the release; for example, "Wine 20040505". Wine is now on a "standard" release track; the most current version as of 8/2006 is 0.9.19.
Year of release
Other examples, identifying versions by year (Adobe Illustrator 88, WordPerfect Office 2003)
Alphanumeric codes
* Macromedia Flash MX
* Adobe Photoshop CS2
Roman numerals
* Apple's Mac OS X, representing version 10
TeX
TeX has an idiosyncratic version numbering system. Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches π. The current version is 3.141592. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. TeX developer Donald Knuth has stated that the "absolutely final change (to be made after my death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.
Apple
Apple has a formalised version number structure based around the NumVersion struct, which specifies a one- or two-digit major version, a one-digit minor version, a one-digit 'bug' (ie revision) version, a stage indicator (drawn from the set development/prealpha, alpha, beta and final/release), and a one-byte (ie having values in the range 0-255) prerelease version, which is only used at stages prior to final. In writing these version numbers as strings, the convention is to omit any parts after the minor version whose value are zero (with 'final' being considered the zero stage), thus writing 1.0.2b12, 1.0.2 (rather than 1.0.2f0), and 1.1 (rather than 1.1.0f0).
Other schemes
Some software producers use different schemes to denote releases of their software. For example, the Microsoft Windows operating system was first labelled with standard numerical version numbers (Windows 1.0 through Windows 3.11), then by years (Windows 95, Windows 98, Windows 2000), and also by alphanumeric codes (Windows Me, Windows XP). The Debian project uses a major/minor versioning scheme for releases of its operating system, but uses code names from the movie Toy Story during development to refer to stable, unstable and testing releases. The Ubuntu GNU/Linux distribution uses the two digit year number followed by the month (4.10, 5.04, 5.10, and 6.06).
Internal version numbers
Software may have an "internal" version number which differs from the version number shown in the product name (and which typically follows version numbering rules more consistently). J2SE 5.0, for example, has the internal version number of 1.5.0, and versions of Windows from 95 on have continued the standard numerical versions internally: Windows 95 is Windows 4.0, 98 is 4.10, 2000 is 5.0, XP is 5.1, 2003 is 5.2, and Vista is 6.0.
Pre-release versions
In conjunction with the various versioning schemes listed above, a system for denoting pre-release versions is generally used. Programs that are in a very early stage of development are often called "alpha" software, after the first letter in the Greek alphabet. After they mature but are not yet ready for release, they may be called "beta" software, after the second letter in the Greek alphabet. Alpha- and beta-version software is often given numerical versions less than 1 (such as 0.9), to suggest their approach toward a public "1.0" release. However, if the pre-release version is for an existing software package (e.g. version 2.5), then an "a" or "alpha" may be appended to the version number. So the alpha version of the 2.5 release might be identified as 2.5a or 2.5.a. Software packages which are soon to be released as a particular version may carry that version tag followed by "rc-#", indicating the number of the release candidate. When the version is actually released, the "rc" tag disappears.
Modifications to the numeric system
Odd-numbered versions for development releases
Up until the 2.6.x series, Linux used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases. For example, Linux 2.3 was a development family of the second major design of the Linux kernel, and Linux 2.4 was the stable release family that Linux 2.3 matured into. After the minor version number in the Linux kernel is the release number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Even further, a trivial version number was added to 2.6.8, making 2.6.8.1 which denoted a very minor change. This fourth number has been made standard since 2.6.11.1.
Apple Computer
Apple had their own twist on this habit during the era of the classic MacOS: although there were minor releases, they rarely went beyond 1, and when they did, they twice jumped straight to 5, suggesting a change of magnitude intermediate between a major and minor release (thus, 8.5 really means 'eight and a half', and 8.6 is 'eight and a half point one'). The complete sequence of versions (neglecting revision releases) is 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (skipping 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.2, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2. OS X has bucked this trend, having gone more conventionally from 10.0 to 10.4, one minor release at a time.
Political significance of version numbers
Version 1.0 as a milestone
Commercial software developers often start at version 1 for the first release of a program and increment the major version number with each rewrite, meaning that a program can reach version 3 within a few months of development, before it's even considered stable or reliable. In contrast to this, the Free Software community tends to use version 1.0 as a major milestone, indicating that the software is "complete", that it has all major features, and is considered reliable enough for general release. In this scheme, the version number slowly approaches 1.0 as more and more bugs are fixed in preparation for the 1.0 release. For example, Firefox released version 0.9, 0.95, and 0.995 as they prepared a "finished" version that would be called Firefox 1.0 The developers of MAME do not intend to release a version 1.0 of their emulator program. The argument is that it will never be truly "finished" because there will always be more arcade games. Version 0.99 was simply followed by version 0.100, even though 0.100 is a smaller decimal number than 0.99.
To describe program history
Winamp released an entirely different architecture for version 3 of the program. Due to lack of backwards compatibility with plugins and other resources from the major version 2, a new version was issued that was compatible with both version 2 and 3. The new version was set to 5 (2+3), jumping version 4.
Keeping up with competitors
There's a common habit in the commercial software industry (usually, though not always, spurned by non-commercial programmers) to make major jumps in numeric major or minor version numbers for reasons which do not seem (to many members of the program's audience) to merit them: "marketing" version numbers. This can be seen in several Microsoft products, as well as Sun Solaris and Java Virtual Machine numbering, SCO Unix version numbers, and Corel Word Perfect, as well as the filePro DB/RAD programming package, which went from 2.0 to 3.0 to 4.0 to 4.1 to 4.5 to 4.8 to 5.0, and is about to go to 5.6, with no intervening release. A slightly different version can be seen in AOL's PC client software, which tends to have only major releases (5.0, 6.0, 7.0, etc...). Also Microsoft Access jumped from version 2.0 to version 7.0, to match the version number of Microsoft Word.
Sun's Java has had the versions:
* JDK 1.0.3
* JDK 1.1.2 through 1.1.8
* J2SE 1.2.0 through 1.4.2
* J2SE 5.0
Significance in software engineering
Version numbers are used in practical terms by the consumer, or client, by being able to compare their copy of the software product against another copy, such as the newest version released by the developer. For the programmer team or company, versioning is often used on a file-by-file basis, where individual parts or sectors of the software code are compared and contrasted with newer or older revisions, often in a collaborative Concurrent Versions System. There is no absolute and definite software version schema; it can often vary from software genre to genre, and is very commonly based on the programmer's personal preference.
Version numbers for files and documents
Some computer file systems, such as the OpenVMS Filesystem, also keep versions for files.
Versioning amongst documents is relatively similar to the routine used with computers and software engineering, where with each small change in the structure, contents, or conditions, the version number is incremented by 1, or a smaller or larger value, again depending on the personal preference of the author and the size or importance of changes made.
Mathematical properties of version numbers
Version numbers very quickly evolve from simple integers (1,2,...) to rational numbers (2.08,2.09,2.10) and then to non-numeric "numbers" such as 4:3.4.3-2. These complex version numbers are therefore better treated as character strings. Operating systems that include package management facilities (such as all non-trivial Linux or BSD distributions) will use a distribution-specific algorithm for comparing version numbers of different software packages. For example, the ordering algorithms of the Red Hat and derived distributions and those of the Debian-like distributions differ.
An ideal ordering algorithm should define a total order on strings. In other words, given two version strings u and v, either u and v should be identical, or u should come before or after v. More formally, if the version comparison algorithm is modeled as a function f(u,v) which returns -1, 0 or 1, the following two properties should hold:
* (A) For all u,v and w, if f(u,v) = -1 and f(v,w) = -1 then f(u,w) = -1 (transitivity),
* (B) For all u and v, if f(u,v) = f(v,u) then u and v should be equal strings (antisymmetry).
Note that (B) also implies reflexivity. If these two conditions do not hold, then we have one of the two situations:
* (I) There is a sequence of version numbers v1,...,vk such that v1<v2<...<vk and vk<v1. In other words, we have a circularity in the version numbering scheme. Version numbers are supposed to reflect software evolution and circularities can wreak havoc with package management systems.
* (II) There exist two different strings u and v such that u and v are equivalent as version numbers.
For instance, in Debian, leading zeroes are ignored in chunks, so that 5.0005 and 5.5 are considered as equal, and 5.5<5.0006. This can confuse users ; string-matching tools may fail to find a given version number ; and this can cause subtle bugs in package management if the programmers use string-indexed data structures such as version-number indexed hash tables.
Note that the ordering of version numbers needs neither be well-founded nor non-Archimedean. The former condition would forbid infinite descending sequences of version numbers. As we live in a finite world, this has no consequence, and in practice, the empty string is usually the minimum of the ordering. The latter would mean that there is always a finite number of versions between two given version numbers. If version strings are unlimited in length, this would mean that it is always possible to insert a new version between two existing versions, which is a desirable feature. It is common for each component of a version number to be treated individually, so that 1.9 need not be followed by 2.0, but by 1.10; it is, as noted above, not safe to assume that mathematical operations can safely be applied to a given version number merely because its representation appears to be that of a real number.
Even though I started the thread, I haven't installed (or would not install) it. Firefox is doing more than enough sort of a job for me. I just wanted the IE Suckers 
D) to get their precious little app asap.
However, for people who are doing Seagulls job, IE is a better choice when it comes to copying and pasting tables (or rows) straight into the Excel Sheets.
D) to get their precious little app asap. However, for people who are doing Seagulls job, IE is a better choice when it comes to copying and pasting tables (or rows) straight into the Excel Sheets.
yeah dats true machan...it makes thngs easy for dat.......... but i normaly use opera...... dats da best for meAnusha said:Even though I started the thread, I haven't installed (or would not install) it. Firefox is doing more than enough sort of a job for me. I just wanted the IE Suckers
However, for people who are doing Seagulls job, IE is a better choice when it comes to copying and pasting tables (or rows) straight into the Excel Sheets.
You do that
I don't feel like evne installing it in a virtual PC. But do you know that IE7 will become a critical update when the final version is released? If you have automatic updates turned on, it will automatically install even without asking (this is the final version I'm talking about; not the beta's or RC's).
I don't feel like evne installing it in a virtual PC. But do you know that IE7 will become a critical update when the final version is released? If you have automatic updates turned on, it will automatically install even without asking (this is the final version I'm talking about; not the beta's or RC's).
