Alaska Software Inc. - Changes to the Installation and Update Processes
Username: Password:
AuthorTopic: 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 AltmannRe: 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 BrandelRe: 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 EscholtRe: 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 HerdtRe: 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 JuracRe: 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 BraunRe: 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 HerdtRe: 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 HerdtRe: 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 HerdtRe: 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