Hello Alaska team,

In another message, Til said:

7. Personally, I haven't had a problem integrating 2.0 into my scheme 
of switching between Xbase++ versions. The fact that I can install 
without changing the environment lets me keep my old scheme, and I can 
still use the Workbench for my 2.0 projects. This goes for my 
development machines.

This is exactly what I would like to do.

I don't mind where the installer puts all the files as long as I can 
easily find the ones that I need such as the .CH files, the 
Distribution DLLs, ...

My concern is simply to be able to use my current method (SUBST) to 
compile with previous versions of Xbase++ while I can also compile the 
new ones with version 2.0.

Can you confirm that installing Xbase V2.0 will NOT distroy my current 
system? Can you also tell me how you did it or what I need to change in 
my system to have this concurrent versions?

Many thanks,
Raymond

Raymond,

at least I can tell you as I work: I also use the SUBST with my earlier 
versions. When it comes to Xbase++ 2.0 I just use either the WorkBench 
oder I right click on a target, "CMD shell". This opens a command line 
with all the settings for this WorkBench.

This means that the WorkBench is "self-containing". It know everything 
about its environment. This will also work with future versions. I.e. 
when Xbase++ 2.5 will be released, you will have this with the 2.5 
WorkBench. You even can have both WorkBenches open the same time.

Regards, Frank

Am 02.10.2014 18:46, schrieb Raymond Fischbach:
> Hello Alaska team,
>
> In another message, Til said:
>
> 7. Personally, I haven't had a problem integrating 2.0 into my scheme of
> switching between Xbase++ versions. The fact that I can install without
> changing the environment lets me keep my old scheme, and I can still use
> the Workbench for my 2.0 projects. This goes for my development machines.
>
> This is exactly what I would like to do.
>
> I don't mind where the installer puts all the files as long as I can
> easily find the ones that I need such as the .CH files, the Distribution
> DLLs, ...
>
> My concern is simply to be able to use my current method (SUBST) to
> compile with previous versions of Xbase++ while I can also compile the
> new ones with version 2.0.
>
> Can you confirm that installing Xbase V2.0 will NOT distroy my current
> system? Can you also tell me how you did it or what I need to change in
> my system to have this concurrent versions?
>
> Many thanks,
> Raymond
>
>

Raymond,

 Just to expand on the "how it's done" part a bit;

if you tell the installer to do a "side-by-side" installation (it's among the options
for the base product in the feature tree), your existing environment will not be
touched. This means that PATH, LIB etc. will still contain their previous values.

There's only one exception: the IDE's installation folder is added to your PATH
variable so that the Workbench can be started from the command line. 

As Frank said in his earlier posting, in this mode ("side-by-side"), the 
environment for developing 2.0 projects is solely provided by the Workbench
and is independent from PATH, LIB etc.. This means that as long you use the 
Workbench (or a CMD shell opened from WITHIN the Workbench), you're set 
for 2.0. Everything run outside the Workbench sits on your PATH, LIB etc.
settings and hence uses whatever version was configured before 2.0 came
along. 

Side note: for this to work, we're using a folder structure which actually 
isn't too different from the old one as far as the tools are concerned. So if
you changed your SUBSTs in the appropriate places, you probably could 
adapt your existing scheme to include 2.0 if you really, really wanted to.

Regards,
  Till.

--------------------------------------------------------------------
Technical Support:         support@alaska-software.com
News Server:                 news.alaska-software.com
Homepage:                     http://www.alaska-software.com
KnowledgeBase:            http://www.alaska-software.com/kb
--------------------------------------------------------------------



"Frank Grossheinrich" schrieb im Newsbeitrag news:297379c5$7ef95cfa$5e29@news.alaska-software.com...
> Raymond,
> 
> at least I can tell you as I work: I also use the SUBST with my earlier 
> versions. When it comes to Xbase++ 2.0 I just use either the WorkBench 
> oder I right click on a target, "CMD shell". This opens a command line 
> with all the settings for this WorkBench.
> 
> This means that the WorkBench is "self-containing". It know everything 
> about its environment. This will also work with future versions. I.e. 
> when Xbase++ 2.5 will be released, you will have this with the 2.5 
> WorkBench. You even can have both WorkBenches open the same time.
> 
> Regards, Frank
> 
> Am 02.10.2014 18:46, schrieb Raymond Fischbach:
>> Hello Alaska team,
>>
>> In another message, Til said:
>>
>> 7. Personally, I haven't had a problem integrating 2.0 into my scheme of
>> switching between Xbase++ versions. The fact that I can install without
>> changing the environment lets me keep my old scheme, and I can still use
>> the Workbench for my 2.0 projects. This goes for my development machines.
>>
>> This is exactly what I would like to do.
>>
>> I don't mind where the installer puts all the files as long as I can
>> easily find the ones that I need such as the .CH files, the Distribution
>> DLLs, ...
>>
>> My concern is simply to be able to use my current method (SUBST) to
>> compile with previous versions of Xbase++ while I can also compile the
>> new ones with version 2.0.
>>
>> Can you confirm that installing Xbase V2.0 will NOT distroy my current
>> system? Can you also tell me how you did it or what I need to change in
>> my system to have this concurrent versions?
>>
>> Many thanks,
>> Raymond
>>
>>
>

Le 2/10/2014, Till Warweg a supposé :
> Raymond,
>
>  Just to expand on the "how it's done" part a bit;
>
> if you tell the installer to do a "side-by-side" installation (it's among the 
> options
> for the base product in the feature tree), your existing environment will not 
> be
> touched. This means that PATH, LIB etc. will still contain their previous 
> values.
>
> There's only one exception: the IDE's installation folder is added to your 
> PATH
> variable so that the Workbench can be started from the command line.
>
> As Frank said in his earlier posting, in this mode ("side-by-side"), the 
> environment for developing 2.0 projects is solely provided by the Workbench
> and is independent from PATH, LIB etc.. This means that as long you use the 
> Workbench (or a CMD shell opened from WITHIN the Workbench), you're set for 
> 2.0. Everything run outside the Workbench sits on your PATH, LIB etc.
> settings and hence uses whatever version was configured before 2.0 came
> along.
>
> Side note: for this to work, we're using a folder structure which actually 
> isn't too different from the old one as far as the tools are concerned. So if
> you changed your SUBSTs in the appropriate places, you probably could adapt 
> your existing scheme to include 2.0 if you really, really wanted to.
>
> --
> Regards,
>   Till.
>
> --------------------------------------------------------------------
> Technical Support:         support@alaska-software.com
> News Server:                 news.alaska-software.com
> Homepage:                     http://www.alaska-software.com
> KnowledgeBase:            http://www.alaska-software.com/kb
> --------------------------------------------------------------------
>
>
>
> "Frank Grossheinrich" schrieb im Newsbeitrag 
> news:297379c5$7ef95cfa$5e29@news.alaska-software.com...
>> Raymond,
>> 
>> at least I can tell you as I work: I also use the SUBST with my earlier 
>> versions. When it comes to Xbase++ 2.0 I just use either the WorkBench oder 
>> I right click on a target, "CMD shell". This opens a command line with all 
>> the settings for this WorkBench.
>> 
>> This means that the WorkBench is "self-containing". It know everything 
>> about its environment. This will also work with future versions. I.e. when 
>> Xbase++ 2.5 will be released, you will have this with the 2.5 WorkBench. 
>> You even can have both WorkBenches open the same time.
>> 
>> Regards, Frank
>> 
>> Am 02.10.2014 18:46, schrieb Raymond Fischbach:
>>> Hello Alaska team,
>>>
>>> In another message, Til said:
>>>
>>> 7. Personally, I haven't had a problem integrating 2.0 into my scheme of
>>> switching between Xbase++ versions. The fact that I can install without
>>> changing the environment lets me keep my old scheme, and I can still use
>>> the Workbench for my 2.0 projects. This goes for my development machines.
>>>
>>> This is exactly what I would like to do.
>>>
>>> I don't mind where the installer puts all the files as long as I can
>>> easily find the ones that I need such as the .CH files, the Distribution
>>> DLLs, ...
>>>
>>> My concern is simply to be able to use my current method (SUBST) to
>>> compile with previous versions of Xbase++ while I can also compile the
>>> new ones with version 2.0.
>>>
>>> Can you confirm that installing Xbase V2.0 will NOT distroy my current
>>> system? Can you also tell me how you did it or what I need to change in
>>> my system to have this concurrent versions?
>>>
>>> Many thanks,
>>> Raymond
>>>
>>>
>> 

Frank and Til,

Thank you very much for these precisions.
I was afraid that the installation would destroy my current 
installations.
Now, I know I can go on 

Thanks again,
Raymond

Frank Grossheinrich wrote:

> Raymond,
> 
> at least I can tell you as I work: I also use the SUBST with my earlier 
> versions. When it comes to Xbase++ 2.0 I just use either the WorkBench 
> oder I right click on a target, "CMD shell". This opens a command line 
> with all the settings for this WorkBench.
> 
> This means that the WorkBench is "self-containing". It know everything 
> about its environment. This will also work with future versions. I.e. 
> when Xbase++ 2.5 will be released, you will have this with the 2.5 
> WorkBench. You even can have both WorkBenches open the same time.

Hi Frank,

I probably will only use the installer once in a VM to "unpack" the
installation and put it into my structure I'm used to.

I also will never use the workbench, as I use MultiEdit and have build
batches of my own.

But what about updates? 

Will there be a ZIPped distribution I can use to update my installation or
do I have to go through the installer for updates as well every time?

Thomas

Hi Thomas,

> Will there be a ZIPped distribution I can use to update my installation or
> do I have to go through the installer for updates as well every time?

No, there will be no zip files. The preferred way to install an update is 
(sorry for that  to start the workbench. This is enough to get informed 
if there are updates available.

Then you will select the update to download and install. Insofar the 
workbench is your update tool.

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
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:mt95fmtlgyky$.1p2ey5db9hqyr$.dlg@40tude.net...
> Frank Grossheinrich wrote:
>
>> Raymond,
>>
>> at least I can tell you as I work: I also use the SUBST with my earlier
>> versions. When it comes to Xbase++ 2.0 I just use either the WorkBench
>> oder I right click on a target, "CMD shell". This opens a command line
>> with all the settings for this WorkBench.
>>
>> This means that the WorkBench is "self-containing". It know everything
>> about its environment. This will also work with future versions. I.e.
>> when Xbase++ 2.5 will be released, you will have this with the 2.5
>> WorkBench. You even can have both WorkBenches open the same time.
>
> Hi Frank,
>
> I probably will only use the installer once in a VM to "unpack" the
> installation and put it into my structure I'm used to.
>
> I also will *never* use the workbench, as I use MultiEdit and have build
> batches of my own.
>
> But what about updates?
>
> Will there be a ZIPped distribution I can use to update my installation or
> do I have to go through the installer for updates as well every time?
>
> Thomas

Andreas Herdt wrote:

> No, there will be no zip files. The preferred way to install an update is 
> (sorry for that  to start the workbench.

Ok - already installed everything in a VM, so I'm set  

> Then you will select the update to download and install. Insofar the 
> workbench is your update tool.

What is "the plan" for testing our software with new releases of Xbase++
(and I'm not talking about 2.x vs. 3.x, but build numbers) while still
maintaining the current release version?

For large projects, it might take days or even weeks until everything is
veryfied to be working.

So how do I keep my main development on .554  while testing with an
(imaginary) build .620?

There might even be the need to keep more than one version running in
parallel.

Do I copy and rename %programfiles%\Alaska Software\xpp20 into
%programfiles%\Alaska Software\xpp20.554 and run the update afterwards?

Or %programfiles%\Alaska Software\ into %programfiles%\Alaska
Software.554\?

How will the workbench be affected by that?

Another question is how to integrate all the 3rd party tools - they need to
be available in different versions as well - currently I have a 3rdParty
folder below each xbase++ build folder.

I think with idea of releasing updates quicker is not only positive - many
development companies don't have the manpower to follow all those updates
that quickly - or they just take the risk that things get broken by new
Xbase++ releases and don't do much testing.

regards
Thomas

Hi Thomas,

> I think with idea of releasing updates quicker is not only positive - many
> development companies don't have the manpower to follow all those updates
> that quickly - or they just take the risk that things get broken by new
> Xbase++ releases and don't do much testing.

This is infact the downside of continues delivery. This makes the difference
between releases for which you have to wait "some time" and  updates where
possibly minor things are changed you are not interrested in.

Let us see how this works out.

From the workbench you will be able to install versions that have been 
installed
already. The workbench manages an update history. Insofar you are able to
return to a save harbour if it turns out that you don't like what you get.

An update is just an offer. It is an option.

  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
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:1a3w4ivzhs945.97mbv0zjvnj5$.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> No, there will be no zip files. The preferred way to install an update is
>> (sorry for that ;-) to start the workbench.
>
> Ok - already installed everything in a VM, so I'm set :-)
>
>> Then you will select the update to download and install. Insofar the
>> workbench is your update tool.
>
> What is "the plan" for testing *our* software with new releases of Xbase++
> (and I'm not talking about 2.x vs. 3.x, but build numbers) while still
> maintaining the current release version?
>
> For large projects, it might take days or even weeks until everything is
> veryfied to be working.
>
> So how do I keep my main development on .554  while testing with an
> (imaginary) build .620?
>
> There might even be the need to keep more than one version running in
> parallel.
>
> Do I copy and rename %programfiles%\Alaska Software\xpp20 into
> %programfiles%\Alaska Software\xpp20.554 and run the update afterwards?
>
> Or %programfiles%\Alaska Software\ into %programfiles%\Alaska
> Software.554\?
>
> How will the workbench be affected by that?
>
> Another question is how to integrate all the 3rd party tools - they need 
> to
> be available in different versions as well - currently I have a 3rdParty
> folder below each xbase++ build folder.
>
> I think with idea of releasing updates quicker is not only positive - many
> development companies don't have the manpower to follow all those updates
> that quickly - or they just take the risk that things get broken by new
> Xbase++ releases and don't do much testing.
>
> regards
> Thomas