Easy way to install releases on Codebase to SQx

Voted for this task.

I Also have an opinion:

Add them by default inside new version of SQX.

Voted for this task.

Alex,

Good point.  However, some folks might have created their own .sxp

My thoughts is similar to the linux repositories where apt-get can add new repositories on top of their official repositories and just do an apt-get install to install the different packages.  This way, for official and personal packages, it would be easy to install.  When there are conflicts with new features, it will not stop the dev team from rolling out new features whilst these individual packages get fixed.

The dev team is busy fixing the core SQX without needing to worry about the other packages, but users will really like to have their modules installed hassle free.  Especially when new versions (proper releases or RC or beta) comes often enough that makes updating a headache.

Voted for this task.

The problem is updates. codebase scripts are updated by users and do not necessarily coincide with sqx updates, you still need to go to the codebase site to get the newest versions when the new indicator version is released. or to even check for new versions of the indicators which often have bugs in the early releases so computers without internet are SOL.
but this is related to this idea, if not an outright duplicate:
https://roadmap.strategyquant.com/tasks/sq4_9857

Voted for this task.

Yes this feature will be fine. 

Voted for this task.

Bentra,

Apologies, did not know that there was another task already created.

You are right that its about the updates not being in sync. 

I had another idea, but slightly complicated.

1. Have a "SQ Hub" program.  The purpose of this is to manage all SQ programs, SQx, Quantanalyzer etc.  It can also used to be a launcher.

2. Users can use SQ Hub to install versions of SQ (e.g. B136, B137RC1, etc....)

3. Data will be in its own segment so that B136 and B137RC1 does not need their own copies of the data, thus reducing the storage space we use.

4. Users can define and configure their own Environment.  (E.g. in Environment A, user can use B136, with a set of codebase add ons.  In Environment B, user can use B137RC1 with other sets of codebase add ons)

This way we can manage different releases without interrupting our workflow too much to try other releases.

What do you guys think?

Btw, the idea above is copied and combined from Unity Hub and Anaconda environments in case developers want to know what i am going on about.

Voted for this task.