Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Upgrading from version to version
#1
General question: When upgrading from one version to another (say 3.4 to 3.5), which files in the upgrade package are really essential to perform the upgrade? For instance, I see in the 3.5 package that all of the c folder has the same rev date as the rest of the package, but I would be surprised if the entire toolchain is upgraded.
Reply
#2
(01-13-2023, 02:34 AM)bobalooie Wrote: General question: When upgrading from one version to another (say 3.4 to 3.5), which files in the upgrade package are really essential to perform the upgrade? For instance, I see in the 3.5 package that all of the c folder has the same rev date as the rest of the package, but I would be surprised if the entire toolchain is upgraded.


The supported way to upgrade is to simply extract to a new directory, in-place upgrades are not recommended and usually result in broken installs due to left-over files from the previous version. That said you can generally determine which files were changed based on the release notes (Ex. If we changed the toolchain, as we did in 3.4.1, we would note in the release notes), but if you run into issues the recommend fix is going to be creating a fresh install.



I definitely recognize in-place upgrades would be nice, perhaps it's something we could take a closer look at.
Reply
#3
(01-13-2023, 02:43 AM)DSMan195276 Wrote:
(01-13-2023, 02:34 AM)bobalooie Wrote: General question: When upgrading from one version to another (say 3.4 to 3.5), which files in the upgrade package are really essential to perform the upgrade? For instance, I see in the 3.5 package that all of the c folder has the same rev date as the rest of the package, but I would be surprised if the entire toolchain is upgraded.


The supported way to upgrade is to simply extract to a new directory, in-place upgrades are not recommended and usually result in broken installs due to left-over files from the previous version. That said you can generally determine which files were changed based on the release notes (Ex. If we changed the toolchain, as we did in 3.4.1, we would note in the release notes), but if you run into issues the recommend fix is going to be creating a fresh install.



I definitely recognize in-place upgrades would be nice, perhaps it's something we could take a closer look at.

Got it. It's a bit of a PITA, but I can deal with it.
Reply
#4
(01-13-2023, 03:05 AM)bobalooie Wrote:
(01-13-2023, 02:43 AM)DSMan195276 Wrote:
(01-13-2023, 02:34 AM)bobalooie Wrote: General question: When upgrading from one version to another (say 3.4 to 3.5), which files in the upgrade package are really essential to perform the upgrade? For instance, I see in the 3.5 package that all of the c folder has the same rev date as the rest of the package, but I would be surprised if the entire toolchain is upgraded.


The supported way to upgrade is to simply extract to a new directory, in-place upgrades are not recommended and usually result in broken installs due to left-over files from the previous version. That said you can generally determine which files were changed based on the release notes (Ex. If we changed the toolchain, as we did in 3.4.1, we would note in the release notes), but if you run into issues the recommend fix is going to be creating a fresh install.



I definitely recognize in-place upgrades would be nice, perhaps it's something we could take a closer look at.

Got it. It's a bit of a PITA, but I can deal with it.

Steve pointed out to me that to preserve IDE settings from version to version all one needs to do is copy .\internal\config.ini from the old version to the new one. That at least saves a little time having to reconfigure the IDE with personal settings.
Reply




Users browsing this thread: 2 Guest(s)