Hi,

What do you think of the attached image regarding:

A) going forward with the Qt Installer Framework for building the installer?

B) the order and inclusion of: Preview for betas; Csound (current and
old releases); Frontends; ... ; Development Snapshots (for periodic
builds of each development branch)?

C) hotfixes? Unlisted in this image, but I'm thinking of treating them
just as regular stable releases. Is that OK? Frontends can recommend or
even force the user to update if they run the installer silently. Would
that be a good idea? Same question for betas.

Finally, csound.com/download can have: 1) an online installer without
any binary data inside; 2) a "heavy" offline installer including all the
latest software; 3) "lightweight" offline installers for each component;
4) a combination of [1+2] or [1+3], e.g., Csound + CsoundQt as part of
the installer, but with the possibility to download and install Cabbage
if that component is selected by the user.

Whatever is decided, and I don't want to upset Rory :) but should
CsoundQt be selected by default in the installer or should we leave that
up to the user?

Cheers.

Hi,

great preparations, Guillermo, thank you! I am very used to similar installer 
for installing Qt itself and it is really comfortable system.

I thinnk the installer itself should be light, online installer -  nowadays 
living offiline is not so typical (although healthy :) ).

I personaly like your solution where there are Preview and betas available  - 
it is socomfortanle for users to get then newest versions and it is easy 
enough to ditinguish between them.

I also agree with Rory that stucturing 
Core - Csound / Frontends is good idea. 

But the idea and plan are great -  I am sure when it gets done it is another 
boost for Csound users to approach it more easily.

Thanks!

tarmo

On Wednesday, November 8, 2017 11:06:05 AM EET you wrote:
> > A) going forward with the Qt Installer Framework for building the
> > installer?
> > 
> > B) the order and inclusion of: Preview for betas; Csound (current and
> > old releases); Frontends; ... ; Development Snapshots (for periodic
> > builds of each development branch)?
> > 
> > C) hotfixes? Unlisted in this image, but I'm thinking of treating them
> > just as regular stable releases. Is that OK? Frontends can recommend or
> > even force the user to update if they run the installer silently. Would
> > that be a good idea? Same question for betas.
> 
> This all sounds good. I think if people wish to use development snapshots
> for a frontends they can get them themselves. I'd be inclined to offer just
> one version of each package rather than several.
> 
> > Finally, csound.com/download can have: 1) an online installer without
> > any binary data inside; 2) a "heavy" offline installer including all the
> > latest software; 3) "lightweight" offline installers for each component;
> > 4) a combination of [1+2] or [1+3], e.g., Csound + CsoundQt as part of
> > the installer, but with the possibility to download and install Cabbage
> > if that component is selected by the user.
> 
> Personally I think we should just offer option 1 alongside a no-frills
> Csound installer that doesn't contain any frontends.
> 
> > Whatever is decided, and I don't want to upset Rory :) but should
> > CsoundQt be selected by default in the installer or should we leave that
> > up to the user?
> 
> Don't worry Guillermo, the only think that upsets me is when people steel
> my beer! With regards to the structure of the installer, could the packages
> be listed as:
> 
> Core
> - Csound
> 
> Frontends (3rd Part)
> - CsoundQT
> - Cabbage
> - Blue
> - Winxsound
> - etc
> 
> I think it would help inform users that the various frontends offered
> aren't part of the official Csound project? I think this point needs to be
> emphasised. Overall this looks like a huge step forward. Thanks again for