I like the idea of the split. The only disadvantage/challenge I see is, that we add another thing to remember, when we introduce new ENVs.

To keep all consistent, we must ensure, that at least the following things are done:

• Add entry to ENVIRONMENT.md
• Add default value to target/scripts/start-mailserver.sh
• Add to function _setup_default_vars in target/scripts/startup/setup-stack.sh

I like the idea of the split. The only disadvantage/challenge I see is, that we add another thing to remember, when we introduce new ENVs.

To keep all consistent, we must ensure, that at least the following things are done:

• Add entry to ENVIRONMENT.md

• Add default value to target/scripts/start-mailserver.sh

• Add in target/scripts/startup/setup-stack.sh

I thought about this too. I could easily put the function _setup_default_vars back in start-mailserver.sh. I will see how that turn out tomorrow, after fixing the conflicts.

I came up with an elegant solution. Similar to what it was like before, I create a dictionary VARS which is just "played back" in _setup_default_vars. And since we are using := the default assignment to the variable itself happens and we can freely use them later as is with default values. I like this, as it eliminates the need to introduce variables in 3 places, as you @casperklein already mentioned.

@casperklein what do you think now? From my side ready for merging.

@aendeavor I will review it tomorrow. But from a quick check it looks good to me 👍

I would like to see this being merged before v9.0.0 is released. @wernerfred I guess you will be releasing v9.0.0 and writing the changelog when all PRs we mentioned in the maintainers team are merged.

So I will gather all changelog information when this get's merged and release v9.0.0 afterwards 🥳

@wernerfred Perfect. This is exactly what I wanted to ask you now :D

@casperklein If you approve this PR, go ahead and squash merge it into master in order to enable the release of v9.0.0 :)

PS: @wernerfred Don't forget to update the README for version 9, especially the setup.sh download section

No deal breaker, just a little styling question:

Before: ################### >> fix funcs

After: # ? >> Fixes

I was just wondering about the "?". What' s the meaning of it? Why not just # >> Fixes

I was just wondering about the "?". What' s the meaning of it? Why not just # >> Fixes

When you're using the "Better Comments" extension some IDEs provide, comments followed by an ? will become blue:

Ah colors.. another general question. You did a great afford in colorizing all the scripts.

echo "-e${3:-}" "[ \e[0;92mTASKLOG\e[0m ] ${2}" ;; # light green

Was there a reason, why you didn't use variables, e.g. \e[0;92m instead of $LGREEN

echo "-e${3:-}" "[ ${LGREEN}TASKLOG${COLOR_RESET} ] ${2}" ;; # light green

This looks IMHO more cleaner.

Maybe I provide a PR in mid-term to switch to variables. But before (wasting time), I want to ensure, there was no particular reason not to so.

Was there a reason, why you didn't use variables, e.g. \e[0;92m instead of $LGREEN

I thought this was more compact:)

This looks IMHO more cleaner.

Feel free to change it. But until supervisor fixes its issues with Color, there is no difference :)