Author | Topic: Changes to the Installation and Update Processes | |
---|---|---|
Andreas Gehrs-Pahl | Changes to the Installation and Update Processes on Tue, 14 Oct 2014 06:07:12 -0400 I would like to request the following changes to the Installation and Update processes for the Alaska Xbase++ development tool. 1) Allow the user to install the Xbase++ application and all its components in user-defined locations/directories: a) Select the directory for Programs (possibly separately for: Workbench, Xbase++, WAA, Help files, etc.) The exact number of individually selectable directories and the level of details depends on what Alaska (and maybe other Xbase++ users) seem as necessary and what directory naming scheme Alaska will (finally) adopt for individual versions and builds. I would be happy with being able to at least select the "Alaska Software" directory name and location. b) Select the directory for Source Code and Samples (possibly separately for: WAA and CXP Samples.) Again, the exact number of individually selectable directories and the level of details depends on what Alaska (and maybe other Xbase++ users) seem as necessary and what directory naming scheme Alaska will (finally) adopt for individual versions and builds. c) The following four directory locations are currently used for this purpose by the Workbench and are saved in the "product.config" file in the User's "\Application Data\Alaska-Software\xpp20" directory: * SiteRootPath (set to: "My Documents\Xbase++\Source\") * WinSamples (set to: "My Documents\Xbase++\Source\Samples\") * WebSamples (set to: "My Documents\Xbase++\Source\WebSamples\") * XppRoot (set to: "Program Files\Alaska Software\XPP20\") d) Adding a few additional Target directories, like: * AlaskaSoftware (default to: "Program Files\Alaska Software\") * CXP (default to: "Program Files\Alaska Software\CXP20\") * WorkBench (default to: "Program Files\Alaska Software\Workbench20\") * HelpFiles (default to: "Program Files\Alaska Software\Help20\") * WAA (default to: "Program Files\Alaska Software\WAA20\") would be a relatively small extension of the current system, and would allow for a very flexible installation and update setup. 2) Make the following changes and additions to the Installation of the Active-X "Redistributables" option: a) Document which DLL/OCX/EXE files will be installed / registered, and which versions of those files are provided, as well as where they are installed (e.g. \Windows\System32\). b) Don't register older/lower-version DLLs/OCXs from your distribution, when newer/higher-version files already exist. The current install program will replace new files with older ones, without asking and without an option to uninstall or un-register those files. c) Let the user select individual Active-X files, by Name and Version, rather than silently install all (or none) behind the scenes. d) Include documentation and/or separate installation files to install all required Active-X "Redistributables" at our client sites. 3) Modify the option to "Change Environment" so it is easier distinguishable from the other installation options. A checkbox on a separate "page" (after selection of the directories) would be much preferable for this item. If this option is NOT selected, don't modify the Path, either. 4) Display the selected installation options -- including the selected directories -- in an easy to read text format on a separate page, before starting the actual installation / update, so the user can review the selections. 5) Alaska's optional web-based activation process is working very well, and is absolutely necessary, so please don't change or remove this option in the future. On the other hand, using the Workbench as the only possible update tool is not working very well (yet). I found the following issues with the Workbench's "Update Manager": a) The "Update Manager" doesn't even display without Internet access, so you can't look at the Installation History, unless the workbench can connect to the Alaska Server. The "Update Manager" should display regardless of Internet access or not. b) The "Automatically check for updates" checkbox is always checked, even if you manually un-check it! The User's selection should be saved and respected. But even if that checkbox is checked, the application doesn't actually seem to check for updates automatically. c) There is (currently) no option to un-install or undo an installation or to roll-back an update, as indicated in the documentation and in several of Alaska's emails and newsgroup posts. 6) Updating from Build 547 to Build 554 using the Workbench revealed the following problems and issues: a) The update took nearly half an hour, while the manual Install as well as a manual Update only took a couple of minutes, even though the exact same MSI file was downloaded and used. One reason for the slowness might be the creation of a 7.5 MB log file, using the Workbench update process. b) After the update process, the (new/updated) Workbench didn't automatically start again. There was no indication that the update process had (successfully) completed. c) The "update" simply replaced ALL files, making it identically to the manual installation of build 554. All build 547 files were deleted. d) There was no list of which files had changed or which files were added or removed. For testing and re-distribution of files, it is essential that all modified, added and removed files are listed and documented somewhere. e) After manually uninstalling the 554 build (after updating to it from build 547 with the workbench), the "\Alaska Software\workbench20\bin" directory couldn't be deleted, until after a reboot, even though all files in that directory had been deleted. 7) Because not all computers have Internet access, using the Workbench as the only way for updates is simply impractical. For small "CDI" updates, separate ZIP files should be provided for manual downloads. This would also solve the following problems/issues: a) Users can manually download the updates and install them in their development environment, even if that environment has no Internet access or can't be connected to the Internet. b) The contents of the ZIP files would immediately show (and document) which files have been changed or added. Deleted/removed files would still have to be documented separately in some sort of ReadMe file. c) Users can determine what (exact) changes were made, specifically in Header and Sample program files, as they can be compared to existing ones, instead of blindly replacing the older ones. d) Creating individual ZIP files, containing all the modified and new files, should be as simple, if not simpler, than creating an MSI Installation for each build update. Creating individual ZIP files (or using named sub-directories in a single ZIP file) for each "Target" directory -- see items 1c) and 1d) above -- would be a feasible option to implement this. This would depend on the actual directory structure for version/build updates, that Alaska will ultimately implement. e) At least at this time, this seems to be the only way for the developer to know which files -- specifically runtime files -- have been changed and need to be re-distributed to customers for each new build/version. I believe the above listed changes are reasonable and will have a relatively small impact on the recurring efforts required by Alaska for creating the Xbase++ updates, while giving us developers the flexibility and freedom to have our own individual development environments. Thanks, Andreas Andreas Gehrs-Pahl Absolute Software, LLC phone: (989) 723-9927 email: Andreas.GP@Charter.net web: http://www.Aerospace-History.net | |
Martin Altmann | Re: Changes to the Installation and Update Processes on Tue, 14 Oct 2014 12:58:03 +0200 Andreas, plenty of thumbs up - thank you for all the work you put into describing the relevant and necessary changes! Regards, Martin ______________________________ Deutschsprachiges Xbase-Forum: http://www.xbaseforum.de/ ______________________________ | |
Hubert Brandel | Re: Changes to the Installation and Update Processes on Tue, 14 Oct 2014 13:18:39 +0200 Am 14.10.2014 12:07, schrieb Andreas Gehrs-Pahl: > 5) Alaska's optional web-based activation process is working very well I do have to disagree with that by now. In the license agreement you are allowed to install 4 pc. After you have changed the OS (new install) or HD/SSD you will have to reactivate the license and you loose one pc. Thats what hapend with my pc after system crash with the HD. It would be OK, if I can just deactivate a pc like I can du with FrameMaker ... | |
Andreas Gehrs-Pahl | Re: Changes to the Installation and Update Processes on Tue, 14 Oct 2014 08:09:56 -0400 Hubert, >I do have to disagree with that by now. I didn't mean that I'm a big fan of the entire activation process, just that the web-based process is required (and works as advertised) as compared to using the workbench to connect to the Internet for activation, which won't work for me. I think that the 4 PCs rule is adequate, but would also prefer to have an option or process to either add more PCs if necessary (for additional VMs, tablets, etc.) or to alternatively de-activate un-needed activation keys instead. As long as the activation (key) is only needed for (automatic) updates, I couldn't care less. If and when the activation (key) will be required to actually compile and link applications, I might be more concerned about this limitation, but for now, that isn't the case. I sometimes have to work on client workstations with limited or no Internet access, and/or very restrictive firewall rules, so the entire "black box" Internet-only update and activation process would really hamper me, if this couldn't be done in an un-connected mode. Anyway, this post was mostly about the Install and Update process, rather than the Activation process. If the activation process will hamper or prohibit me from working with Xbase++ in the future, I will certainly raise my voice, but for right now, I'm okay with the status quo. Andreas Andreas Gehrs-Pahl Absolute Software, LLC phone: (989) 723-9927 email: Andreas.GP@Charter.net web: http://www.Aerospace-History.net | |
Jan Escholt | Re: Changes to the Installation and Update Processes on Tue, 14 Oct 2014 18:32:43 +0200 Andreas, many many thanks to your absolutely detailed compilation of thinks that need to be improved by Alaska Software. I agree with every single sentence. Jan Am 14.10.2014 um 12:07 schrieb "Andreas Gehrs-Pahl": > I would like to request the following changes to the Installation and Update > processes for the Alaska Xbase++ development tool. > | |
Andreas Gehrs-Pahl | Re: Changes to the Installation and Update Processes on Tue, 14 Oct 2014 14:57:59 -0400 I just updated to version 2.0.556, using the 2.0.554 workbench. The behavior was the same as before, with a couple of minor changes: 5b) The "Automatically check for updates" check box seems to be working as expected now, even though the option is still checked by default, and can't be disabled until after selecting the "Update Manager", which will result in at least one automatic connection/update attempt. 6a) I observed that the first 20+ Minutes of the update were taken up by completely deleting the existing 2.0.554 files in the "Program Files" and "My Document" folders, while creating the verbose log file. I would recommend to have the verbose logging disabled or to have at least an option/setting to allow this to be disabled, as it is extremely and unnecessary time consuming. 6e) Using the Task Manager, I this time "killed" the "xwb.exe" process that was started after the update completed -- but which never actually started the WorkBench. This allowed the Un-Install process to completely remove the "Alaska Software" directory, without requiring a reboot. After I uninstalled 2.0.556, I used the downloaded MSI file to manually install 2.0.556 from scratch, which resulted in a complete installation and an identical copy of the previous "update", while taking barely a couple of minutes. So, all three recent "Updates" -- 547 (RC-1), 554, and now 556 -- are complete and full installations, without any incremental updates or any option to roll-back anything -- or any indication of which files were changed, added or deleted. Thanks, Andreas Andreas Gehrs-Pahl Absolute Software, LLC phone: (989) 723-9927 email: Andreas.GP@Charter.net web: http://www.Aerospace-History.net | |
Andreas Herdt | Re: Changes to the Installation and Update Processes on Wed, 15 Oct 2014 19:47:39 +0200 Hi Andreas, Thank you very much for your detailed listing of issues you have found and the summary of what you would expect from the Update/Installation process. Many of your suggestions will be respected in future updates. However, we see that not all of them make sense from our perspective. Again, thank you very much for your effort. This is very appreciated. Andreas Herdt Alaska Software -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm Fax European Office: +49 (0) 61 96 - 77 99 99 23 Fax US Office: +1 (646) 218 1281 -------------------------------------------------------------------- "Andreas Gehrs-Pahl" wrote in message news:1nz6gfw5stt0y.zd753qxgknaq$.dlg@40tude.net... >I would like to request the following changes to the Installation and >Update > processes for the Alaska Xbase++ development tool. > > 1) Allow the user to install the Xbase++ application and all its > components > in user-defined locations/directories: > > a) Select the directory for Programs (possibly separately for: > Workbench, > Xbase++, WAA, Help files, etc.) The exact number of individually > selectable directories and the level of details depends on what > Alaska > (and maybe other Xbase++ users) seem as necessary and what directory > naming scheme Alaska will (finally) adopt for individual versions and > builds. I would be happy with being able to at least select the > "Alaska Software" directory name and location. > > b) Select the directory for Source Code and Samples (possibly separately > for: WAA and CXP Samples.) Again, the exact number of individually > selectable directories and the level of details depends on what > Alaska > (and maybe other Xbase++ users) seem as necessary and what directory > naming scheme Alaska will (finally) adopt for individual versions and > builds. > > c) The following four directory locations are currently used for this > purpose by the Workbench and are saved in the "product.config" file > in the User's "\Application Data\Alaska-Software\xpp20" directory: > * SiteRootPath (set to: "My Documents\Xbase++\Source\") > * WinSamples (set to: "My Documents\Xbase++\Source\Samples\") > * WebSamples (set to: "My Documents\Xbase++\Source\WebSamples\") > * XppRoot (set to: "Program Files\Alaska Software\XPP20\") > > d) Adding a few additional Target directories, like: > * AlaskaSoftware (default to: "Program Files\Alaska Software\") > * CXP (default to: "Program Files\Alaska Software\CXP20\") > * WorkBench (default to: "Program Files\Alaska > Software\Workbench20\") > * HelpFiles (default to: "Program Files\Alaska Software\Help20\") > * WAA (default to: "Program Files\Alaska Software\WAA20\") > would be a relatively small extension of the current system, and > would allow for a very flexible installation and update setup. > > 2) Make the following changes and additions to the Installation of the > Active-X "Redistributables" option: > > a) Document which DLL/OCX/EXE files will be installed / registered, and > which versions of those files are provided, as well as where they are > installed (e.g. \Windows\System32\). > > b) Don't register older/lower-version DLLs/OCXs from your distribution, > when newer/higher-version files already exist. The current install > program will replace new files with older ones, without asking and > without an option to uninstall or un-register those files. > > c) Let the user select individual Active-X files, by Name and Version, > rather than silently install all (or none) behind the scenes. > > d) Include documentation and/or separate installation files to install > all required Active-X "Redistributables" at our client sites. > > 3) Modify the option to "Change Environment" so it is easier > distinguishable > from the other installation options. A checkbox on a separate "page" > (after selection of the directories) would be much preferable for this > item. If this option is NOT selected, don't modify the Path, either. > > 4) Display the selected installation options -- including the selected > directories -- in an easy to read text format on a separate page, before > starting the actual installation / update, so the user can review the > selections. > > 5) Alaska's optional web-based activation process is working very well, > and > is absolutely necessary, so please don't change or remove this option in > the future. On the other hand, using the Workbench as the only possible > update tool is not working very well (yet). I found the following issues > with the Workbench's "Update Manager": > > a) The "Update Manager" doesn't even display without Internet access, so > you can't look at the Installation History, unless the workbench can > connect to the Alaska Server. The "Update Manager" should display > regardless of Internet access or not. > > b) The "Automatically check for updates" checkbox is always checked, > even > if you manually un-check it! The User's selection should be saved and > respected. But even if that checkbox is checked, the application > doesn't actually seem to check for updates automatically. > > c) There is (currently) no option to un-install or undo an installation > or to roll-back an update, as indicated in the documentation and in > several of Alaska's emails and newsgroup posts. > > 6) Updating from Build 547 to Build 554 using the Workbench revealed the > following problems and issues: > > a) The update took nearly half an hour, while the manual Install as well > as a manual Update only took a couple of minutes, even though the > exact same MSI file was downloaded and used. One reason for the > slowness might be the creation of a 7.5 MB log file, using the > Workbench update process. > > b) After the update process, the (new/updated) Workbench didn't > automatically start again. There was no indication that the update > process had (successfully) completed. > > c) The "update" simply replaced ALL files, making it identically to the > manual installation of build 554. All build 547 files were deleted. > > d) There was no list of which files had changed or which files were > added > or removed. For testing and re-distribution of files, it is essential > that all modified, added and removed files are listed and documented > somewhere. > > e) After manually uninstalling the 554 build (after updating to it from > build 547 with the workbench), the "\Alaska Software\workbench20\bin" > directory couldn't be deleted, until after a reboot, even though all > files in that directory had been deleted. > > 7) Because not all computers have Internet access, using the Workbench as > the only way for updates is simply impractical. For small "CDI" updates, > separate ZIP files should be provided for manual downloads. This would > also solve the following problems/issues: > > a) Users can manually download the updates and install them in their > development environment, even if that environment has no Internet > access or can't be connected to the Internet. > > b) The contents of the ZIP files would immediately show (and document) > which files have been changed or added. Deleted/removed files would > still have to be documented separately in some sort of ReadMe file. > > c) Users can determine what (exact) changes were made, specifically in > Header and Sample program files, as they can be compared to existing > ones, instead of blindly replacing the older ones. > > d) Creating individual ZIP files, containing all the modified and new > files, should be as simple, if not simpler, than creating an MSI > Installation for each build update. Creating individual ZIP files (or > using named sub-directories in a single ZIP file) for each "Target" > directory -- see items 1c) and 1d) above -- would be a feasible > option > to implement this. This would depend on the actual directory > structure > for version/build updates, that Alaska will ultimately implement. > > e) At least at this time, this seems to be the only way for the > developer > to know which files -- specifically runtime files -- have been > changed > and need to be re-distributed to customers for each new > build/version. > > I believe the above listed changes are reasonable and will have a > relatively > small impact on the recurring efforts required by Alaska for creating the > Xbase++ updates, while giving us developers the flexibility and freedom to > have our own individual development environments. > > Thanks, > > Andreas > -- > Andreas Gehrs-Pahl > Absolute Software, LLC > > phone: (989) 723-9927 > email: Andreas.GP@Charter.net > web: http://www.Aerospace-History.net | |
Andreas Gehrs-Pahl | Re: Changes to the Installation and Update Processes on Wed, 15 Oct 2014 14:30:10 -0400 Andreas, >Many of your suggestions will be respected in future updates. Thank you very much! >However, we see that not all of them make sense from our >perspective. Would you mind telling me/us, which of the requests will be accepted and which ones make no sense to you? If you could also let me/us know the reasons why those rejected requests make no sense to you? Maybe I can clarify the reasons why they might be important for me/us and convince you to implement them anyway, or maybe there are workarounds available, to make this work for everyone. Thank you for your response, Andreas Andreas Gehrs-Pahl Absolute Software, LLC phone: (989) 723-9927 email: Andreas.GP@Charter.net web: http://www.Aerospace-History.net | |
Matej Jurac | Re: Changes to the Installation and Update Processes on Thu, 16 Oct 2014 09:51:53 +0200 Just give developers .zip files for complete development environment as one of options of distribution. Most of developers are actually quite knowledgeable how to use such software distribution. All you would need would be one zip with complete install tree and second with only modified files. And of course .reg files if you depend on registry (i presume you do). And you can keep setup.exe and integrated update manager. One reason why I have a second thoughts about update only via workbench: - how to reliably test if new release (2.xxx -> 2.(xxx+1) ) is really better and stabler than previous release while having both releases ready on same machine (I do, but not all have access to unlimited number of vm's/machines) - if a new bug is introduced in compiler/libraries a rollback to previous release is hard because (actually there is no info known) there is no simple way for 100% accurate rollback in place. With zip it is easy to do, you just keep trees of installs in place. You install base variant and select few upgrades, right? - even if compiler/linker/libs of distro is right, change in compiler/headers can resoult add-on libs fail to compile or link, so you have to roll back changes. - if Alaska goes out of business there is currently no way of having all necessary setup files downloaded and ready to recover IDE/compiler/tools in case of crash. A few suggestions too: - open up on information of all kinds, it will cost you absolutely zero to publish pdf's of user manuals, screenshots of Wb in action, and a video or two while (quote "We expect the new trial version to become available within next two to three months."). - as I read, you plan to introduce new site for alaska-software.com based on CXP pages, right? How about include source of it into distribution as real-life example on how to make cxp work. - Eclipse IDE | |
Thomas Braun | Re: Changes to the Installation and Update Processes on Thu, 16 Oct 2014 14:06:59 +0200 Matej Jurac wrote: > - Eclipse IDE lol - nice joke. Do you really expect Alaska to throw away all the work put into their workbench and do it all over again so Xbase++ works with Eclipse? Thomas | |
Andreas Herdt | Re: Changes to the Installation and Update Processes on Thu, 16 Oct 2014 14:46:11 +0200 Hello Mr Jurac, Thank you very much for your contributions and suggetions. I am sure they will be taken into consideration. Andreas Herdt Alaska Software -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm Fax European Office: +49 (0) 61 96 - 77 99 99 23 Fax US Office: +1 (646) 218 1281 -------------------------------------------------------------------- "Matej Jurac" wrote in message news:be5241$7812d8cf$143ad@news.alaska-software.com... > Just give developers .zip files for complete development environment as > one of > options of distribution. Most of developers are actually quite > knowledgeable > how to use such software distribution. All you would need would be one zip > with complete install tree and second with only modified files. And of > course > .reg files if you depend on registry (i presume you do). > > And you can keep setup.exe and integrated update manager. > > One reason why I have a second thoughts about update only via workbench: > > - how to reliably test if new release (2.xxx -> 2.(xxx+1) ) is really > better > and stabler than previous release while having both releases ready on same > machine (I do, but not all have access to unlimited number of > vm's/machines) > > - if a new bug is introduced in compiler/libraries a rollback to previous > release is hard because (actually there is no info known) there is no > simple > way for 100% accurate rollback in place. With zip it is easy to do, you > just > keep trees of installs in place. You install base variant and select few > upgrades, right? > > - even if compiler/linker/libs of distro is right, change in > compiler/headers > can resoult add-on libs fail to compile or link, so you have to roll back > changes. > > - if Alaska goes out of business there is currently no way of having all > necessary setup files downloaded and ready to recover IDE/compiler/tools > in > case of crash. > > A few suggestions too: > > - open up on information of all kinds, it will cost you absolutely zero to > publish pdf's of user manuals, screenshots of Wb in action, and a video or > two > while (quote "We expect the new trial version to become available within > next > two to three months."). > > - as I read, you plan to introduce new site for alaska-software.com based > on > CXP pages, right? How about include source of it into distribution as > real-life example on how to make cxp work. > > - Eclipse IDE | |
Andreas Herdt | Re: Changes to the Installation and Update Processes on Thu, 16 Oct 2014 15:24:41 +0200 Hello Mr Jurac, > - if Alaska goes out of business there is currently no way of having all > necessary setup files downloaded and ready to recover IDE/compiler/tools > in > case of crash. The topic is the update mechanism. We will provide certain builds as ordenary releases on our homepage for download. As the uncertainty is with the update process the situation does not differ to other software products where updates are no longer available if the vendor of the product disappears. With my best regards, Andreas Herdt Alaska Software -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm Fax European Office: +49 (0) 61 96 - 77 99 99 23 Fax US Office: +1 (646) 218 1281 -------------------------------------------------------------------- "Matej Jurac" wrote in message news:be5241$7812d8cf$143ad@news.alaska-software.com... > Just give developers .zip files for complete development environment as > one of > options of distribution. Most of developers are actually quite > knowledgeable > how to use such software distribution. All you would need would be one zip > with complete install tree and second with only modified files. And of > course > .reg files if you depend on registry (i presume you do). > > And you can keep setup.exe and integrated update manager. > > One reason why I have a second thoughts about update only via workbench: > > - how to reliably test if new release (2.xxx -> 2.(xxx+1) ) is really > better > and stabler than previous release while having both releases ready on same > machine (I do, but not all have access to unlimited number of > vm's/machines) > > - if a new bug is introduced in compiler/libraries a rollback to previous > release is hard because (actually there is no info known) there is no > simple > way for 100% accurate rollback in place. With zip it is easy to do, you > just > keep trees of installs in place. You install base variant and select few > upgrades, right? > > - even if compiler/linker/libs of distro is right, change in > compiler/headers > can resoult add-on libs fail to compile or link, so you have to roll back > changes. > > - if Alaska goes out of business there is currently no way of having all > necessary setup files downloaded and ready to recover IDE/compiler/tools > in > case of crash. > > A few suggestions too: > > - open up on information of all kinds, it will cost you absolutely zero to > publish pdf's of user manuals, screenshots of Wb in action, and a video or > two > while (quote "We expect the new trial version to become available within > next > two to three months."). > > - as I read, you plan to introduce new site for alaska-software.com based > on > CXP pages, right? How about include source of it into distribution as > real-life example on how to make cxp work. > > - Eclipse IDE | |
Carlos A Beling | Re: Changes to the Installation and Update Processes on Thu, 16 Oct 2014 12:59:33 -0300 Hello Matej: good afternoon. I read carefully your post and, in despite I have my subscription updated, I decided to wait for to download Xbase++ 2.0 after many questions about installation folders and updates to be solved: it will to be less expensive to me because my 1.90 version is working fine and I do not have enough resources for to modify my IDE for being according to the new one rules safety and quickly. Fraternally Beling Em 16/10/2014 04:51, Matej Jurac escreveu: > Just give developers .zip files for complete development environment as one of > options of distribution. Most of developers are actually quite knowledgeable > how to use such software distribution. All you would need would be one zip > with complete install tree and second with only modified files. And of course > .reg files if you depend on registry (i presume you do). > > And you can keep setup.exe and integrated update manager. > > One reason why I have a second thoughts about update only via workbench: > > - how to reliably test if new release (2.xxx -> 2.(xxx+1) ) is really better > and stabler than previous release while having both releases ready on same > machine (I do, but not all have access to unlimited number of vm's/machines) > > - if a new bug is introduced in compiler/libraries a rollback to previous > release is hard because (actually there is no info known) there is no simple > way for 100% accurate rollback in place. With zip it is easy to do, you just > keep trees of installs in place. You install base variant and select few > upgrades, right? > > - even if compiler/linker/libs of distro is right, change in compiler/headers > can resoult add-on libs fail to compile or link, so you have to roll back changes. > > - if Alaska goes out of business there is currently no way of having all > necessary setup files downloaded and ready to recover IDE/compiler/tools in > case of crash. > > A few suggestions too: > > - open up on information of all kinds, it will cost you absolutely zero to > publish pdf's of user manuals, screenshots of Wb in action, and a video or two > while (quote "We expect the new trial version to become available within next > two to three months."). > > - as I read, you plan to introduce new site for alaska-software.com based on > CXP pages, right? How about include source of it into distribution as > real-life example on how to make cxp work. > > - Eclipse IDE > | |
Andreas Herdt | Re: Changes to the Installation and Update Processes on Thu, 16 Oct 2014 14:57:54 +0200 Hi Andreas, Your posting was quite clear. I am sure we understand each individual request/demand and the ratio behind. If you have doupts any point was misleading or in danger not being understood correctly please precise the point. I really don't think this is required. For further discussions I am not preparred and I want to avoid providing any false or misleading information. I understand your impatience in this matter. I would assume the first modifications to the installation procedure will be done before the end of this year. No guarantee on this. Overall it is not a simple task to improve and extend the entire procedure to have it done the way we really would liked to have it. Many of your requirements will be fullfilled on the way anyway. Thank you for your understanding. Thanks to everybody else for each indifvidual contribution in this thread. Andreas Herdt Alaska Software -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm Fax European Office: +49 (0) 61 96 - 77 99 99 23 Fax US Office: +1 (646) 218 1281 -------------------------------------------------------------------- "Andreas Gehrs-Pahl" wrote in message news:1633ouyk82pcx$.1oqatrkbdun97$.dlg@40tude.net... > Andreas, > >>Many of your suggestions will be respected in future updates. > > Thank you very much! > >>However, we see that not all of them make sense from our >>perspective. > > Would you mind telling me/us, which of the requests will be accepted and > which ones make no sense to you? If you could also let me/us know the > reasons why those rejected requests make no sense to you? Maybe I can > clarify the reasons why they might be important for me/us and convince > you to implement them anyway, or maybe there are workarounds available, > to make this work for everyone. > > Thank you for your response, > > Andreas > -- > Andreas Gehrs-Pahl > Absolute Software, LLC > > phone: (989) 723-9927 > email: Andreas.GP@Charter.net > web: http://www.Aerospace-History.net |